Skip to content

Conversation

iangregory
Copy link
Contributor

I have been investigating the performance of predbat and generated some flame graphs to see where it was spending most of it's time each run. Even on a run with no replan, predbat was taking around 1m10s to run, and a full run was taking ~2m40s.

predbat-noreplan

Delving into this more deeply revealed that about 80% of the time taken during a "no replan" run was spent fetching history (fetch_sensor_data) from Home Assistant. I have days_previous set to look back 14 days, so fetching this much history each run is time consuming.

This PR introduces a (disabled by default) in-memory caching mechanism for Home Assistant history data to improve performance. On first run, the cache will be populated with the history data. Subsequent runs will evict older data and request only new data from Home Assistant. The cache is not persisted; a restart will cause it to be fully re-populated. A config option allows it to be enabled/disabled.

Runtimes reduced to 0m36s (no replan)/1m11s (full run) with the cache enabled. I've been running this since last week with no obvious issues.

Summary of changes:

  • Added a new config option history_cache_enable to allow enabling/disabling the in-memory cache for Home Assistant history data (apps/predbat/config.py).
  • Implemented the HistoryCache class for thread-safe, in-memory caching of history data (apps/predbat/history_cache.py).
  • Integrated the history cache into the Home Assistant interface: initialized the cache, added a method to configure it, and updated the history fetching logic to use the cache when enabled (apps/predbat/ha.py).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant