Profiler GUI

Since ADTF version 3.3.0 ADTF3 comes with built-in profiling support based upon easy_profiler. To make use of it and analyze your instance, threads and blocks, the code must be instrumented.

How to instrument my code for profiling?

To add profiling blocks to your own code, just #include <easy/profiler.h> and use the supplied macros from easy_profiler. For example just use the EASY_FUNCTION() macro in each of your functions you want to profile.

For a more in-depth documentation take a look at https://github.com/yse/easy_profiler.

Capture Profiling Data

The ADTF SDKs and Services are already instrumented so you can start profiling right away.

adtf_launcher --profiler
For more options use
adtf_launcher --help
regarding profiling support.

You can now launch the profiler_gui.exe executable located in the bin folder of your ADTF delivery. Click the connect button and check the available profiling blocks with the help of the according button in the toolbar. There you can select which blocks you want to record, but most of the time you can just leave them all enabled. Make sure the ADTF Session is doing whatever you want to profile and then hit the Capture button in the toolbar. Press stop when you have collected enough data.

We recommend to use the delivered .bat (Windows) / .sh (Linux) files to start. The Profiling GUI needs to know where the Qt delivery is located, which will be set by these scripts.

Analyse Profiling Data

The following screenshot shows a profiling ADTF Session of the example ADTF Session Processing using timer and thread:

Profiler GUI
The upper bar graph shows all threads and their executed blocks. You can select a time range with pressed right mouse-button and get detailed information in the lower tree view. Clicking and hovering the mouse over a block will give you a pop-up with detailed statistics. The bar graph in the center will then show you the execution time over the whole capture period, there you can spot any spikes easily.

In our example we can observe that the timer_runner first executes the trigger function of Demo Time Triggered Filter 2 then the trigger function of Demo Time Trigger 1 followed by the execution of the trigger function of Demo Data Trigger.

When taking a look at the thread runner we see that the trigger function of the Demo Thread Triggered Filter is executed in a busy loop fashion. Right after the Demo Data Trigger has processed its output we see an increase in the execution time on this thread as well, as this trigger function is waiting for some data to be available.

Where to go next?

If not already done, you should have a valid license to use our tools and framework - for that, use the Licenser Tool to get it.