process_defer_queue_() follows the same fast-path/slow-path pattern
as cleanup_() and process_to_add(): an atomic load + branch that
skips to the slow path only when work is pending. GCC currently
inlines it, but past experience shows the compiler can change its
mind when surrounding code changes. Use ESPHOME_ALWAYS_INLINE to
lock in the intended behavior.
process_to_add() has the same pattern as cleanup_(): a one-line
inline fast path (check if to_add_ is empty) with the slow path
already out-of-line in process_to_add_slow_path_(). GCC inlines it
on ESP8266 but not on ESP32, emitting a 20-byte out-of-line body.
Use ESPHOME_ALWAYS_INLINE to guarantee inlining on all platforms.
Verified on ESP32 (xtensa-esp32):
- process_to_add() symbol eliminated from binary
- Scheduler::call() idle path: 1 out-of-line call (millis_64 only)
On ESPHOME_THREAD_SINGLE platforms (ESP8266), move the
Millis64Impl::compute() body into the header so it can be inlined at
call sites. The function is trivial: two static loads, a rollover
branch (taken every ~49.7 days), a store, and a shift+add.
The static storage (last_millis_, millis_major_) is declared as class
statics in the header and defined in time_64.cpp so all TUs share one
copy. Multi-threaded paths remain out-of-line in time_64.cpp.
Also force-inline millis_64_from_() which wraps compute() — GCC was
creating an $isra$ clone instead of inlining the wrapper.
Verified on ESP8266 (xtensa-lx106):
- Millis64Impl::compute() and millis_64_from_ symbols eliminated
- Scheduler::call() idle path: zero out-of-line calls (was 1)
- compute body inlined into 3 call sites (Scheduler::call,
next_schedule_in, loop/millis_64)
cleanup_() has a two-line fast path (check to_remove count, return
!items_.empty()) with the slow path already out-of-line in
cleanup_slow_path_(). Despite `inline` hint, GCC on Xtensa emits it
as a separate function, adding unnecessary call overhead on every
Scheduler::call() invocation even when there is nothing to clean up.
Use ESPHOME_ALWAYS_INLINE to guarantee inlining. Verified on ESP8266:
- cleanup_() symbol eliminated from binary
- Scheduler::call() grows 4 bytes (inlined fast path)
- Net savings: 23 bytes (27-byte out-of-line body removed)
- Idle loop path: 1 out-of-line call instead of 2
Replace heap-allocated SensorWithDedup wrapper with inline
LazySensorWithDedup that stores the sensor pointer and deduplicator
directly in the component, eliminating heap allocations and reducing
RAM usage for configured sensors.
J. Nick Koston