You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that the emitting of the trace code is relatively slow. It takes a few percentages (6%) of the total duration of a restore script. Including Localhost traffic to the database.
First I disabled all the listeners inside the app config. This brought it down to 0.7% of the total time needed to rescript the db.
I propose one additional minor tweak to prevent formatting the message at all. That brings the required processing time down to 0.088%.
i must say that the tracecode is absolutly slow!
In the original sourcecode (4.7.0.0) is have added a static property for DebugTrace on/off.
The Command-Object itselfs check this property before issueing the traceoutput.
Now i have checked the improvement (i run the compiled build not in the die so i have no tracelistener).
In my solution i Need to copy a complete table from one database to another.
If you have more fields to insert the Performance slows down dramaticalliy, for example:
Table with 100 Columns:
with Trace on 2694 Inserts per second.
with Trace off 4459 Inserts per second.
To configure the trace only in the application manifest is not a solution.
The improvement is roundabout 70% !!!!!
I don't want to make my own release-build if it is also simple to make a configurable property or method.
Tested on Notebook I7-64 Bit Windows 8.1, 2,2 Ghz.
Submitted by: Alexander Muylaert-Gelein (gonline)
Is related to DNET467
Attachments:
Start.png
FirstOptimization.png
SecondOptimization.png
code.txt
Hi
I noticed that the emitting of the trace code is relatively slow. It takes a few percentages (6%) of the total duration of a restore script. Including Localhost traffic to the database.
First I disabled all the listeners inside the app config. This brought it down to 0.7% of the total time needed to rescript the db.
I propose one additional minor tweak to prevent formatting the message at all. That brings the required processing time down to 0.088%.
Commits: b046b47
The text was updated successfully, but these errors were encountered: