Types of Profiling

This tutorial discusses the types of profiling that Performance Validator provides, and the strengths and weaknesses of each approach. The tutorial concludes with a brief description of how to use each type of profiling for the maximum benefit.

Sampled profiling

Performance Validator supports sampled profiling. Sampled profiling provides an instant launch of your application without the overhead of any instrumentation. Sampled profiling works by periodically stopping all executing threads and collecting the callstack for each thread, analysing the callstack for how often a given source code file and line occurs, then restarting each thread. Over a period of time, a statistical analysis of the number of lines visited and how often each line is visited can provide insight into the application’s performance.

Strengths

• Instant application launch/ application attach.
• No instrumentation overhead.
• Useful for getting a “quick view” on the application behaviour.

Weaknesses

• Results are statistical, rather than time based.
• Line timing cannot be performed when sampling is used.
• Performance collectors cannot be performed when sampling is used.
• Cannot restrict collected data to a selected part of the application.

Instrumentation profiling

Performance Validator supports instrumentation profiling. Instrumentation profiling provides accurate timing information as well as information about the number of visits to a function or source code line. Performance Validator offers a selection of different timing options, some faster than others, some more accurate than others, each with a different trade off (typically, accuracy increases as speed decreases).

Strengths

• Timing information is more accurate than sampling information.
• Line timing can be used to gather information about time consuming lines in algorithms.
• Performance collectors can be used to collect data only in certain parts of the application.
• Instrumentation can be restricted to certain parts of the application.
• Useful for getting an “accurate view” on the timing of individual parts of the application.

Weaknesses

• Launching the application requires instrumentation.
• Collecting the timing information has a time overhead.

Conclusion

It may at first seem an either / or scenario – “which type of profiling do I use?”.

Fortunately the sampling and instrumentation methods are complementary and can be used hand-in-hand. Typically, when a performance problem is first identified, you will select the “Sampling” mode and run a few tests to identify the area of your application that is running slowly, then switch to an appropriate instrumentation mode (with optional restrictions on which parts of the application are profiled), then repeat your tests using the instrumentation mode. Finally if you think individual parts of an algorithm are the cause of the performance problem, you can enable line timing to identify which lines in a particular algorithm take up all the time.