HamClock's desktop/web build still spends a frankly silly amount of CPU in steady state, not because it is doing lots of useful work, but because the earth map sweep immediately starts again after every completed pass. Several overlays look "instant", but only because the map never gets a chance to be idle. On my local 3-minute benchmark with -t 100 and no live client attached, the master branch sat at about 71% CPU once warm.
-t helps, but is a lot of hammer for a small nail. It lowers CPU by injecting sleep into the same main loop that also handles redraw, touch, and web/API work, so under load it buys headroom by buying latency. There is related discussion in #120 - fixed caps and loop checks are easy to add, but they are not free, and they can change behaviour in awkward places.
The underlying problem seems to be that passive redraw is permanent instead of scheduled. The practical fix is to let the map go idle between passive sweeps, while triggering an immediate redraw when map-visible data actually changes. That keeps DX, PSK, ONTA, DXPeds, ADIF, lightning, and explicit map actions prompt, without keeping the whole map engine running flat out all day like a determined little space heater. I have a branch which does exactly that, keeps -L 0 as an eager compatibility mode, and brings the same local benchmark down to about 1.8% CPU at the default lazy setting, or about 4.0% with eager redraw preserved.
HamClock's desktop/web build still spends a frankly silly amount of CPU in steady state, not because it is doing lots of useful work, but because the earth map sweep immediately starts again after every completed pass. Several overlays look "instant", but only because the map never gets a chance to be idle. On my local 3-minute benchmark with
-t 100and no live client attached, the master branch sat at about 71% CPU once warm.-thelps, but is a lot of hammer for a small nail. It lowers CPU by injecting sleep into the same main loop that also handles redraw, touch, and web/API work, so under load it buys headroom by buying latency. There is related discussion in #120 - fixed caps and loop checks are easy to add, but they are not free, and they can change behaviour in awkward places.The underlying problem seems to be that passive redraw is permanent instead of scheduled. The practical fix is to let the map go idle between passive sweeps, while triggering an immediate redraw when map-visible data actually changes. That keeps DX, PSK, ONTA, DXPeds, ADIF, lightning, and explicit map actions prompt, without keeping the whole map engine running flat out all day like a determined little space heater. I have a branch which does exactly that, keeps
-L 0as an eager compatibility mode, and brings the same local benchmark down to about1.8%CPU at the default lazy setting, or about4.0%with eager redraw preserved.