One issue when trying to profile a “live” application is that you may be getting a lot of noise, resulting from a particular library or section of code being executed from multiple contexts.

You may also be after profiling only one particular case, and want some reproducibility between runs… in short: you want a finer grained control on when or for what the profiling will take place.

In those cases, you can control SamplingProfiler‘s samples collection from your code with the following:

OutputDebugString('SAMPLING ON');
 ...whatever needs to be profiled...
 OutputDebugString('SAMPLING OFF');

Those calls to OutputDebugString() are understood as commands to turn sampling ON or OFF. Usually you’ll want to use this in conjunction with the “Start sampling on command only” option, but it can also be used in reverse to “pause” sample collection. OutputDebugString() is declared in the Windows.pas unit.

As of version 1.5.2, another command that is accepted via OutputDebugString() is ‘SAMPLING THREAD threadID’, which is used to define from which threadID samples must be collected. This is useful when you want to profile a particular thread in multi-threaded application… but that’s another can o’worms for another day!