Post-process Analysis of Measurements Using VTune™ Profiler
You can see the sequence and duration of tasks on the timeline, as shown in the following screenshot. This can be useful to correlate the tasks with other events collected by VTune™ Profiler to better understand the behavior of the workload and analyze the sources of latency outliers.
The screenshot is based on execution of the
with the following parameters:
Since VTune™ Profiler and the measurement library collector use different settings and formats for storing the trace data, it’s not possible to open the latency dump file written by the measurement library from VTune™. You need to re-run the measurement under VTune™ Profiler, but the instrumentation of your workload stays the same, and no code changes are required.
When VTune™ Profiler launches the instrumented application, the associated collector is automatically loaded. This means the workflows of the measurement library collector will not work in this scenario, as indicated by the red “X” in the diagram below.
The following diagram demonstrates the flow for this scenario:
The real-time application is instrumented with Instrumentation and Tracing Technology API (ITT API) and it is linked against
ITT Notify static library (
). At runtime, the static library reads the environment variable
and loads the collector dynamic library for VTune™ Profiler. The collector creates internal structures for storing the data and communicates the results to the application which initialized the measurement. The results of the measurements are available in the VTune™ Profiler user interface.
The real-time application uses measurement library functions to access the measurement structure. In this case, the application is linked against
the measurement library (
), a static library. The measurement library reads the environment variable
and loads the collector for VTune™ Profiler. As a result, the application cannot access the measurement structure expected from the measurement library collector. The
call will return the error code
shared library is linked by the real-time application (through
) to handle internal function calls.