What are the startup options?
The startup options allow to customize some aspects of profiling. These options can be configured when you start the profiled application.
When should I specify the startup options?
In most cases, you do not have to specify any of these options, except for those explicitly presented on the Welcome screen, because default behavior suits fine in most cases.
How can I specify the startup options?
These options can be configured when you start the profiled application:
- on the Welcome screen, using available controls or "Advanced startup options..."
-
if you enable profiling remotely, there are following possibilities (top items in the list are of higher priority):
-
Value of environment variable
YNP_STARTUP_OPTIONS -
Content of file
<user home directory>\.ynp\config\startup-options.ini(in the home directory of the user under which the profiled application runs) -
Value of registry key
HKEY_LOCAL_MACHINE\SOFTWARE\YNP\STARTUP_OPTIONS
-
Value of environment variable
The options are comma-separated if you specify more than one option.
Description of the startup options
|
Main options These options can be switched on startup only, i.e. corresponding behavior cannot be altered during runtime. |
|
port=<value>
|
Specify the port that the profiler agent listens on for communication with the Profiler. |
telemetrylimit=<hours> |
The telemetry information is remembered inside the profiler agent. This allows to connect to profiled application on demand, being able to discover how the application has behaved in the past. By default, the telemetry buffer is limited to store approximately 1 hour of recent telemetry data.
With the help of the Do not use unnecessarily long buffers Extending the telemetry buffer will allocate additional amount of memory in the profiled application's address space. That is especially important for 32-bit processes because total process memory is limited. Also, the longer the buffer, the more time it takes to retrieve the telemetry information from the profiler agent when you connect to a long running profiled application. The limit is not exact It is not guaranteed that data will be kept within exactly specified hours. hours is rather an approximation; the actual time may slightly (+/- 5 minutes) differ to ensure best performance. |
telemetryperiod=<milliseconds> |
Specify how often telemetry information is obtained. By default, the period is 1 second (1000 milliseconds). Note that setting smaller period can add overhead. |
onexit=memory |
Always capture a memory snapshot on exit. |
onexit=snapshot |
Capture recorded data (telemetry, and if recorded CPU profiling results) on exit. CPU snapshot will be captured automatically if CPU profiling is enabled when the profiled application exits. |
|
Control which profiling modes are turned on right from the start Note that you do not have to perform measuring right from the start. Instead, in many cases it's better to start or stop measuring at a later moment - from the UI or by using the Profiler API. |
|
sampling |
Launch application with CPU sampling turned on. Note that you do not have to profile CPU right from the start; instead, in many cases it's better to start or stop measuring at a later moment - from the UI or by using the Profiler API. |
tracing |
Launch application with CPU tracing turned on. Note that you do not have to profile CPU right from the start; instead, in many cases it's better to start or stop measuring at a later moment - from the UI or by using the Profiler API. This option cannot be used in combination with 'disabletracing'. |
alloceach=<N> |
Launch application with object allocation recording started and record each N-th allocation. This option can be used in combination with 'allocsizelimit'. This option cannot be used in combination with 'disablealloc'. Note that you do not have to record allocations right from the start; instead, you can start or stop recording later from the Profiler or using Profiler API. |
allocsizelimit=<B> |
Launch application with object allocation recording started and record allocation of objects with size bigger or equal B bytes. This option can be used in combination with 'alloceach'. This option cannot be used in combination with 'disablealloc'. Note that you do not have to record allocations right from the start; instead, you can start or stop recording later from the Profiler or using Profiler API. |
usedmem=<used memory in megabytes> |
Automatically capture a memory snapshot when process used memory reaches the threshold. |
periodicperf=<period in seconds> |
Periodically capture performance snapshots.
Note that only one of
|
periodicmem=<period in seconds> |
Periodically capture memory snapshots.
Note that only one of
|
|
Optimization options Reduce profiling overhead by disabling some profiling capabilities. See also: Profiling overhead: how to reduce or avoid. These options can be switched on startup only, i.e. corresponding behavior cannot be altered during runtime. |
|
disablealloc |
Do not instrument bytecode with instructions needed for object allocation recording. See also: Profiling overhead: how to reduce or avoid. |
disabletracing |
Do not instrument bytecode with instructions needed for CPU tracing. Only CPU sampling will be available. See also: Profiling overhead: how to reduce or avoid. |
disableall |
Disable several capabilities at once:
|