how does the profiler work?

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?

Comments

  • Hi.

    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 :-)
  • ANTS is at heart an instrumenting profiler, which is to say that it modifies the program(s) being profiled to contain extra code to measure timings and hit counts. This means that it captures a great deal of detail, but it will change the way your program runs. Usually this appears as a constant factor (and hence can be ignored in the results), but can become significant if two parts of the program that take similar amounts of run time get different amounts of instrumentation: for example, a part that calls a lot of functions vs one that calls very few: with the profiler attached the part that calls fewer functions will run more quickly.

    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.
    Andrew Hunter
    Software Developer
    Red Gate Software Ltd.
  • Chris, the brown bag is a term used for a informational presentation given by someone to their team, usually around lunch time. Attendees could bring their own lunch (hence the name "brown bag", since traditionally lunches were packaged in a brown paper bag). Now the term is generically mean "informational presentation"
  • Hi,

    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
Sign In or Register to comment.