Chapter 4. API Guides
Overview Optimizing execution speed is a key element of software performance. Code that executes faster can
also have other positive effects, like reducing overall power consumption. However, improving execution speed may
have trade-offs with other aspects of performance such as Minimizing Binary Size.
Choose What To Optimize If a function in the application firmware is executed once per week in the background,
it may not matter if that function takes 10 ms or 100 ms to execute. If a function is executed constantly at 10 Hz, it
matters greatly if it takes 10 ms or 100 ms to execute.
Most application firmwares will only have a small set of functions which require optimal performance. Perhaps
those functions are executed very often, or have to meet some application requirements for latency or throughput.
Optimization efforts should be targeted at these particular functions.
Measuring Performance The first step to improving something is to measure it.
Basic Performance Measurements If measuring performance relative to an external interaction with the world,
you may be able to measure this directly (for example see the examples wifi/iperf and ethernet/iperf for measuring
general network performance, or you can use an oscilloscope or logic analyzer to measure timing of an interaction
with a device peripheral.)
Otherwise, one way to measure performance is to augment the code to take timing measurements:
#include "esp_timer.h"
void measure_important_function(void) {
const unsigned MEASUREMENTS = 5000;
uint64_t start = esp_timer_get_time();
for (int retries = 0; retries < MEASUREMENTS; retries++) {
important_function(); // This is the thing you need to measure
}
uint64_t end = esp_timer_get_time();
printf("%u iterations took %ull milliseconds (%ull microseconds per␣
,→invocation)\n",
MEASUREMENTS, (end - start)/1000, (end - start)/MEASUREMENTS);
}
Executing the target multiple times can help average out factors like RTOS context switches, overhead of measure-
ments, etc.
• Using esp_timer_get_time() generates“wall clock”timestamps with microsecond precision, but has
moderate overhead each time the timing functions are called.
• It’s also possible to use the standard Unix gettimeofday() and utime() functions, although the over-
head is slightly higher.
• Otherwise, including hal/cpu_hal.h and calling the HAL function cpu_hal_get_cycle_count()
will return the number of CPU cycles executed. This function has lower overhead than the others. It is good
for measuring very short execution times with high precision.
• If making “microbenchmarks”(i.e. benchmarking only a very small routine of code that runs in less than
1-2 milliseconds) then flash cache performance can sometimes cause big variations in timing measurements
depending on the binary. This happens because binary layout can cause different patterns of cache misses in a
particular sequence of execution. If the test code is larger then this effect usually averages out. Executing a small
function multiple times when benchmarking can help reduce the impact of flash cache misses. Alternatively,
move this code to IRAM (see Targeted Optimizations).
External Tracing The Application Level Tracing library allows measuring code execution with minimal impact on
the code itself.
Espressif Systems 1440
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General