how does the profiler work?
steve.burkett
Posts: 16
I've been asked to present a brownbag on using this profiler, and am anticipating questions from devs asking how this profiler works (does it hook into prolog/epilog, time intervals polling, etc?)
Also, what's the impact of this tool on the "real" performance of the code? do the performance times reported by the tool reflect this?
Also, what's the impact of this tool on the "real" performance of the code? do the performance times reported by the tool reflect this?
Comments
Thanks for your question.
Obviously I can't go into too much details about the exact techniques of the application but the general technique is one of IL injection and using the perfomance counter objects supplied by the Framework.
You are correct in what you say about the overhead this causes - ususally you would hardly notice the effect of the profiler but certain code blocks (such as very tight loops) can give an exaggerated effect. However, the profiler does use an algorithm to calculate this overhead and it is an option whether to include the raw or the calculated timings.
I have one question now - what's a "brown bag"? (its not a common expression this side of the pond :-)
It does try to compensate for this: the nature of modern processors makes it impossible to completely accurately predict the way the code inserted by the profiler will behave, but the errors usually average out over long periods of time. This means that when you use the profiler, you might see the effects of the instrumentation causing the performance to change, but when you read the results this effect is compensated for. There is an option to turn this off if you want to see the raw results.
There are still effects that can't be compensated for: in particular, the data the profiler produces will mean that there is less cache space available to the program being profiled, and the instrumentation will change the way instructions are scheduled by the processor. Usually these effects have a negligible impact on the performance compared to that of the instrumentation itself, but may be worth bearing in mind.
You can reduce these effects by turning down the amount of detail captured by the profiler. The first thing to try is turning on function inlining in the options: inlined functions won't be instrumented and time used by functions that .NET inlines will be incorporated into their parent functions, so you will get less detail but more accurate results. The next thing to do is to try using one of the less detailed modes: turning off line-level timings or measuring the time spent in functions without source will reduce the amount of work the profiler has to do, and consequently the influence it has on the performance of the target application.
Software Developer
Red Gate Software Ltd.
I don't know if you are interested in memory profiling as well but we have an early access build of our new memory profiler available from this forum:
http://www.red-gate.com/messageboard/viewforum.php?f=92
Build 611 is the current early build.
Stephen