I am working on replacing the current (ugly) SQL parser of dbscript by a nice grammar-based parser as outlined in previous posts. That part of the project has been idle for some months now, but it’s time to integrate a grammer-based parser.
During tests I found that the new parser takes several minutes to parse an SQL file, whereas the old one processed the same file within seconds. Where is this time spent?
When you start the CLRProfiler.exe application, both a console window and a WinForm window open. (This may look unusual, but hey, it’s a developer tool, and it is the functionality that counts)
Click on Start Application to select the executable you want to profile. The application starts up and you perform the tasks to profile just as if you started the application directly. (It just takes a little longer than usual, because the profiler does its work in the background).
When you’re done, close the application. (You may also choose the profiler’s Kill Application button). The profiler will now compute its magic numbers while message “Progress loading (filename).log” is displayed. After computation has finished, a Summary window displays memory and garbage collection statistics.
Click on the Allocated bytes Histogram button, and find the classes with most objects instantiated during the run.
For my purposes, the View Function Graph command was the most useful. It shows the percentage of time spent by each called function relative to the calling function.
It is not obvious from the UI, but each box representing a function can be drilled down by double-clicking it, showing again the percentages of the sub functions. (My guess is that only functions of the same assembly are shown in one graph, and the drill-down is necessary to switch between assemblies).
Anyway, I like that tool, as it showed me in just two (!!) graphs where the code spent its time, and as it turned out, these were just debugging routines (create XML document, retrieve its OuterText property, write to Console).