From 154023f0177c956b896afb0152cc18137b64c9f8 Mon Sep 17 00:00:00 2001 From: "J. Nick Koston" Date: Tue, 2 Sep 2025 11:04:42 -0500 Subject: [PATCH] preen --- esphome/core/scheduler.cpp | 6 +++--- esphome/core/scheduler.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/esphome/core/scheduler.cpp b/esphome/core/scheduler.cpp index a8cebf3e9e..78024a206f 100644 --- a/esphome/core/scheduler.cpp +++ b/esphome/core/scheduler.cpp @@ -14,7 +14,7 @@ namespace esphome { static const char *const TAG = "scheduler"; -static const uint32_t MAX_LOGICALLY_DELETED_ITEMS = 10; +static const uint32_t MAX_LOGICALLY_DELETED_ITEMS = 6; // Half the 32-bit range - used to detect rollovers vs normal time progression static constexpr uint32_t HALF_MAX_UINT32 = std::numeric_limits::max() / 2; // max delay to start an interval sequence @@ -765,12 +765,12 @@ void Scheduler::recycle_item_(std::unique_ptr item) { if (!item) return; - // Pool size of 8 is a balance between memory usage and performance: + // Pool size of 10 is a balance between memory usage and performance: // - Small enough to not waste memory on simple configs (1-2 timers) // - Large enough to handle complex setups with multiple sensors/components // - Prevents system-wide stalls from heap allocation/deallocation that can // disrupt task synchronization and cause dropped events - static constexpr size_t MAX_POOL_SIZE = 8; + static constexpr size_t MAX_POOL_SIZE = 10; if (this->scheduler_item_pool_.size() < MAX_POOL_SIZE) { // Clear callback to release captured resources item->callback = nullptr; diff --git a/esphome/core/scheduler.h b/esphome/core/scheduler.h index 50cc8da366..300e12117d 100644 --- a/esphome/core/scheduler.h +++ b/esphome/core/scheduler.h @@ -325,7 +325,7 @@ class Scheduler { // Memory pool for recycling SchedulerItem objects to reduce heap churn. // Design decisions: // - std::vector is used instead of a fixed array because many systems only need 1-2 scheduler items - // - The vector grows dynamically up to MAX_POOL_SIZE (8) only when needed, saving memory on simple setups + // - The vector grows dynamically up to MAX_POOL_SIZE (10) only when needed, saving memory on simple setups // - This approach balances memory efficiency for simple configs with performance for complex ones // - The pool significantly reduces heap fragmentation which is critical because heap allocation/deallocation // can stall the entire system, causing timing issues and dropped events for any components that need