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.
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.
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).
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.