small optimization in case of many state updates

Author: stas-sl

components/sound_level_meter/sound_level_meter.cpp

@@ -87,11 +87,27 @@ void SoundLevelMeter::setup() {
 }
 
 void SoundLevelMeter::loop() {
-  std::lock_guard<std::mutex> lock(this->defer_mutex_);
   if (!this->defer_queue_.empty()) {
-    auto &f = this->defer_queue_.front();
-    f();
-    this->defer_queue_.pop_front();
+    std::lock_guard<std::mutex> lock(this->defer_mutex_);
+    // Process no more than 5 items per loop iteration.
+    // When there are many sensors with short update intervals,
+    // a large number of state updates (publish_state) may be queued.
+    // Publishing state is a relatively expensive operation, so calling
+    // it more than 10–20 times per iteration could trigger a warning
+    // that the component is taking too long to operate. Therefore, we
+    // limit the number of updates per iteration. The loop runs approximately
+    // 100 times per second, so any remaining items will be processed
+    // in the next iteration. Processing only one item per iteration is too
+    // restrictive, as in extreme cases with many updates - say, 
+    // 100 per second - we might hit performance limits. Thus, we set a maximum 
+    // of 5 items per iteration, allowing up to 500 sensor updates per second
+    // in theory, which should be more than sufficient for most scenarios.
+    uint32_t max_items = std::min(this->defer_queue_.size(), (size_t) 5);
+    for (int i = 0; i < max_items; i++) {
+      auto &f = this->defer_queue_.front();
+      f();
+      this->defer_queue_.pop_front();
+    }
   }
 }
 

configs/10-bands-spectrum-analyzer-example-config.yaml

@@ -69,7 +69,7 @@ sound_level_meter:
   warmup_interval: 500ms
   task_stack_size: 4096
   task_priority: 2
-  task_core: 0 # or you can try core 1
+  task_core: 1
   mic_sensitivity: -26dB
   mic_sensitivity_ref: 94dB
   offset: 0dB