2 Commits

Include renames

Author	SHA1	Message	Date
markfrancisonlyandGitHub	397f5253a5	Rate events over at least one second (#24455) ... * Rate events over at least one second EventsPerSecond.eps() divided the event count by the time since start(), which can be a few milliseconds right after a restart. Frames buffered during an ffmpeg restart then report as 100+ fps, and the same happens to the detector fps. Use a window of at least one second. * Keep sub-second windows consistent Floor the divisor at the window length when the window is shorter than a second, so a caller with a sub-second window still gets its true rate.	2026-09-24 06:28:00 -06:00
3 people	d982b3a782	perf(util): use monotonic clock and bounded deque in EventsPerSecond (#23520) ... * perf(util): use monotonic clock and bounded deque in EventsPerSecond EventsPerSecond is updated on every captured frame, every detection and every processed frame across all cameras and detectors. The previous implementation derived timestamps from datetime.now().timestamp() (wall clock), so an NTP or manual clock adjustment could skew the rolling-window expiry; it also stored timestamps in a list and expired them with del self._timestamps[0] (O(n) per removal) plus a periodic slice-copy to cap growth. Switch to time.monotonic() for the interval math (correct by construction and immune to wall-clock jumps) and a collections.deque(maxlen=...) so expiry is O(1) (popleft) and retention is bounded automatically. This mirrors the deque-based expiry already used in video/ffmpeg.py and watchdog.py. Observable output is unchanged. Adds frigate/test/test_builtin.py covering rate calculation, window expiry and the memory bound. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test: drop test_timestamps_are_memory_bounded It only asserted that deque(maxlen=) caps length, which is stdlib behavior rather than something this change needs to verify. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-21 07:38:41 -06:00