Support Board
Date/Time: Wed, 08 Apr 2026 13:20:13 +0000
Post From: OS Timers vs SC Timers discussion again... SC Timers chart update limitations
| [2026-01-22 18:06:25] |
| n8trading - Posts: 69 |
|
Sounds good, I'll give it a shot when available. Is there a more architectural approach that could be taken here rather than relying on a fixed “Minimum Delay” throttle? From my testing, the issue with SC timers does not appear to be overall CPU saturation, but rather scheduling pressure and UI contention when chart updates are triggered very aggressively. The minimum delay setting does help preserve UI responsiveness, but it does so by reducing effective chart update frequency, which results in noticeably slower updates compared to using OS timers. I’m wondering if it would be possible to address this more directly, for example by: - Slightly backing off or coalescing SC timer wake-ups so they don’t fire additional update work when a chart update is already pending, and/or - Further decoupling chart update scheduling and processing from the UI thread, ensuring that timer-driven work cannot block or starve UI execution (even indirectly via scheduling contention). Personally, I would be very comfortable with somewhat higher CPU utilization if it meant being able to use SC timers with both responsive UI behavior and chart update speed comparable to (or hopefully better than) OS timers, without having to compromise between the two. Overall SC performance is good, but there are a few scenarios where brief UI stalls are noticeable (for example when switching between SIM and non-SIM mode, or when starting/stopping replays). It seems possible that further separation of timer-driven work and/or chart processing into more isolated execution paths could help reduce those stalls as well. I’m raising this mainly because the current behavior suggests the limitation is not raw performance, but how update work is scheduled under load. |