Performance tip: replace $year with $week in hilo.inc has_data check

27 views
Skip to first unread message

EdwinZ

unread,
Aug 2, 2026, 11:09:52 AM (9 days ago) Aug 2
to weewx-user

If you're running the SeasonsEcowitt skin (or any skin derived from it) and noticing high CPU usage and slow report generation, check line 233 of hilo.inc:

#elif $x[3] == '1' and (($getattr($year, $x[0]).has_data) or ('wx_binding' in $txt and $getattr($year(data_binding=$txt), $x[0]).has_data) or ($year.wind.has_data and ($x[0] == 'windavg' or $x[0] == 'windrms' or $x[0] == 'windrms' or $x[0] == 'windvecavg')))

This check uses $year to determine whether to display observations in the statistics table. On a database with 6+ years of data (~640,000 archive records), this triggers MySQL to scan the entire year's worth of raw archive records for every observation in the hilo table — even though the year timespan is not displayed in the statistics table at all.

Impact on my 6-year MySQL database:

  • Report generation time: 4 minutes 10 seconds
  • MySQL archive table scans per report: 39 full-year scans (Jan 1 → present, ~640k records each)

Fix: Replace $year with $week on that line:

#elif $x[3] == '1' and (($getattr($week, $x[0]).has_data) or ('wx_binding' in $txt and $getattr($week(data_binding=$txt), $x[0]).has_data) or ($week.wind.has_data and ($x[0] == 'windavg' or $x[0] == 'windrms' or $x[0] == 'windrms' or $x[0] == 'windvecavg')))

Since $week data is already loaded for the statistics table, this change adds zero additional queries.

Result:

  • Report generation time: 31 seconds (from 4:10 → 0:31, 87% reduction)
  • No functional change — the statistics table displays identically

Environment: weewx 5.4.0, Python 3.14.4, Fedora 43, MySQL backend, ~640,000 archive records (6 years), SeasonsEcowitt skin 5.1.0

Reply all
Reply to author
Forward
0 new messages