Advanced Options
By using the "-silent" parameter in the command line it is possible automatically, and silently profiler an application. The command line should look like:
SamplingProfiler -silent ApplicationName.exe
if you want to profile an exe with the default profiling options, or if you want more control, save your settings to an SPP file and use
SamplingProfiler -silent ProjectName.spp
In both cases, SamplingProfiler will startup, minimize itself into a tray icon, start the specified application specified, profile it for as long as it runs or was specified in the project options, and then save the results to a .spr file alongside the profiled application (results file name is auto-generated from the application name and the date/time).
Parameters present after the application or project name will be passed to the application when it starts up (and they will overwrite parameters defined in the profiling project).
The debug information must be present in or alongside the executable to get detailed profiling information during the silent profiling.
Controlling Profiling from the Profiled Application
The application being profiled can pause and resume samples gathering by the profiler by sending it debug messages. To stop sampling collection use
OutputDebugString('SAMPLING OFF')
and to resume sampling collection use
OutputDebugString('SAMPLING ON')
The effects are similar to using the "pause" button in the SamplingProfiler interface (and will be reflected there). Used in conjunction with "Start sampling on command only" option, you can sample specific areas of the application.
Threading Samples Gathering Modes
Single-Threaded Mode
Samples will be gathered from a single thread, by default the main process thread. In a multi-threaded application, you can select which thread samples are gathered from by signaling it to the profiler by using the following debug message:
OutputDebugString('SAMPLING THREAD threadID')
Replace threadID by the thread ID you want sampled, use 0 to specify the main thread (default behavior). If an incorrect thread ID is specified, no samples will be collected. (see below).
Monte-Carlo Mode
Each sample will be taken from a randomly chose thread of the the process. Note that to limit overhead, only 1 thread is looked at for each sample, which may or may not have been active at the sampling time (if it hasn't, sample will be discarded). The more threads you have, the more varied their relative priorities, the longer it may take to gather meaningful statistics.
There are two options to limit sampling depending on CPU load, either at the process level or at the system level. This allows getting profiling information only when your process is generating a high CPU workload, or when the machine is under a high CPU stress (from your application or other applications).
The process CPU load is understood as a fraction of the CPU cores you process is allowed to run on (in the process affinities). If you enabled your process to run only on one core, then the CPU load will be the load of that single core, if you enabled two cores for instance, then you process will be seen as using 50% CPU if it keeps one of those two cores fully busy and the other not, even if the machine has four cores.
The system CPU load is understood as the total CPU load, f.i. a dual-core system is one core at 100% and the other at 0% will be seen as a 50% load, on a quad-core, a single core at 100% results in a 25% load.
The CPU usage is currently evaluated at a 250ms frequency, ie. CPU-usage-based sampling can miss at most the first 250ms of a CPU usage spike, and sample at most 250ms after a CPU usage spike has ended.
Note that CPU-usage sampling may lead to I/O and other waits disappearing from the profiling results, as these are situations of low CPU usage.
You can adjust the number of samples taken per second, can adjust the delay after application startup before sampling data is collected (f.i. to eliminate the initialization or data loading phase from the analysis), and for how long data should be collected.
You can also choose if you want to begin sampling immediately after the process is created, or only when the application starts (ie. when DLL loading and process initialization has completed). If you're not sure what this means, leave it at the default value ;)
There are two filtering options, which allows to ignore Application.Idle system calls (ie. when the application is idle and waiting for input) and "System.pas" caller (will hide internals like dynamic method resolution, SetLength, internal move copies, etc.).
Finally it is possible to adjust processor affinity of SamplingProfiler and the profiled application during its execution. This option can be used to determine if your code is affected by OS scheduling and load balancing, or to isolate SamplingProfiler from the application to improve reproduceability.
Once a profiling session has completed, the status bar will display the total amount of samples taken, you can obtain a more detailed count and the CPU time used by SamplingProfiler itself during the profiling session via the hint of the StatusBar panel.
Created with the Personal Edition of HelpNDoc: Easily create EPub books