WarnIfComponentBlockingGuard compares the `now` passed to
scheduler.call() against real millis() in finish(). Using fake time
ahead of real millis() caused uint32_t underflow in the guard, triggering
blocking warnings. Fix by reading real millis() at the start of each
outer iteration so fake time stays close to wall clock.
millis_64_from_() tracks 32-bit rollovers, so going backwards in time
would appear as a ~49 day forward jump. Keep now monotonically
increasing across all iterations. With 2000 inner iterations per outer
iteration, overflow is not a practical concern.
- Remove trailing " from AUTO GENERATED INCLUDE BLOCK END comment
- Reset scheduler `now` at start of each outer iteration to avoid
unbounded growth toward UINT32_MAX across benchmark iterations
Three benchmarks covering the most common ESP_LOGW patterns:
- Logger_NoFormat: plain string, no format specifiers (fastest path)
- Logger_3Uint32: 3x uint32_t (common for status/diagnostics)
- Logger_3Float: 3x float with precision (common for sensor values)
Under valgrind, 2000 inner iterations take long enough in wall clock
to trigger WarnIfComponentBlockingGuard. Use a BenchComponent subclass
that sets warn_if_blocking_over_ to UINT16_MAX to prevent log noise.
Adds Scheduler_Call_5IntervalsFiring: 5 intervals with 1ms period,
time advancing each inner iteration so all 5 fire every call().
This benchmarks the real scheduler hot path where callbacks execute.
Sub-microsecond benchmarks are dominated by the ~60ns per-iteration
valgrind start/stop cost in CodSpeed simulation mode. Add kInnerIterations
(1000) inner loops to all fast benchmarks so the actual work dominates.
Move DoNotOptimize calls outside inner loops to prevent artificial overhead.
Also address review feedback:
- Use tokenless CodSpeed (public repo, no CODSPEED_TOKEN needed)
- Fix warning message to show component-specific path
- Fix stray ". :" in error message
- Verify pinned SHA on re-runs to prevent stale checkouts
- Call original_setup() in benchmark main.cpp so code-generated App
initialization (pre_setup, area/device registration, looping_components_
init) runs before benchmarks
- Restore ApplicationLoop_Empty benchmark that calls the actual App.loop()
- Remove BM_ prefix from all benchmark names (unnecessary convention)
- Remove bench_application_loop.cpp (App needs pre_setup/setup which
requires full code generation; will revisit as integration benchmark)
- Fix extra_include_dirs to use os.path.relpath for sibling directories
Core is not a component — its benchmarks belong in tests/benchmarks/core/
not tests/benchmarks/components/core/. Add extra_include_dirs parameter
to build_and_run to support non-component benchmark directories.
J. Nick Koston