Software-based tracing always means some processing overhead, where the exact amount is f x e, where f is the average event frequency and e is the average execution time for storing an event. This is very dependent on your application and processor. The more RTOS calls, the larger overhead. The faster processor, the less overhead.
Let’s put in some typical numbers. The execution time for storing an event is typically a few microseconds on a 32-bit MCU, so lets used 3 µs for e. The average event rate is typically a few thousand per second, so lets use 5000 Hz for f. That would mean an overhead of 5000 Hz x 0.000003 s = 1,5%.
To minimize the processing overhead, try the following:
- Make sure to enable at least basic optimization in your compiler (e.g., -O1).
- If using snapshot mode, you may exclude less important events, as described in the Recorder API documentation.
- Use streaming instead of snapshot mode. The snapshot mode is optimized for memory efficiency, while the streaming recorder is optimized for speed and considerably faster. Streaming can customized via stream ports, for all sorts of target-host interfaces, or even for streaming to device file systems
- If using streaming mode, make sure that the transfer is not blocking the execution in case of full buffers. Use non-blocking transfer mode and if Tracealyzer then reports missing events, the throughput is usually the problem. Fix that by tuning the stream port settings (e.g., larger buffer) or by using a faster transmission channel (e.g, USB or a better debug probe).
Some of our customers keeps the recorder enabled in production code, e.g., using the snapshot mode as a “flight recorder”. In this way, the recorder becomes an integrated part of the system instead of an extra overhead. This way, you can get traces from real world issues, that otherwise may be very hard to reproduce. This can make a huge difference when troubleshooting customer problems.