sascha/esphome
1
0
Fork 0
mirror of https://github.com/esphome/esphome.git synced 2025-09-27 07:32:22 +01:00
Code Issues Releases Wiki Activity

preen

Browse Source
This commit is contained in:
J. Nick Koston
2025-09-02 11:04:42 -05:00
parent 50f5728c76
commit 154023f017
2 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
esphome/core/scheduler.cpp
View File

@@ -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<uint32_t>::max() / 2;
// max delay to start an interval sequence
@@ -765,12 +765,12 @@ void Scheduler::recycle_item_(std::unique_ptr<SchedulerItem> 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;

2
esphome/core/scheduler.h
View File

@@ -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