mirror of
https://github.com/esphome/esphome.git
synced 2026-09-02 02:56:01 +00:00
J. Nick Koston
f9b87d0ede
The fixed MAX_POOL_SIZE=5 cap was the source of the heap churn the pool was meant to prevent: any device with more than 5 concurrent timers (e.g. a board with 30+ LD2450 sensors) hit a steady-state oscillation of recycle->delete and acquire->new on every loop iteration. Replace std::vector<SchedulerItem*> with a singly-linked freelist threaded through SchedulerItem::next_free, which shares storage with `component` via an anonymous union (zero per-item overhead -- the component pointer is dead while pooled). Drop the cap entirely: the freelist quiesces at the application's natural concurrent-timer high-water mark, which is the working set the device already needs while those timers are active. No std::vector means no growth-doubling slack and no realloc copies during warm-up. Caller of get_item_from_pool_locked_() must overwrite item->component before unlocking (already true at the sole call site); nullptr remains a valid live `component` value for SELF_POINTER items, so we cannot pre-clear it.
