Bug: one worker thread pegs a full core per instance, even when idle
Summary
Every running instance of crabcode keeps one single worker thread spinning at ~100% of one CPU core continuously, even when completely idle (no inference, no streaming, TUI untouched). With several sessions open this multiplies: 8 instances ≈ 8 cores burned 24/7.
Environment
- crabcode v0.0.10 (bun global install, prebuilt binary)
- Linux x86_64, kernel 6.17.9-arch1-1, 16 cores
- Multiple instances running in parallel terminals (7–8 sessions)
Evidence
Measured via /proc/<pid>/task/*/stat (utime+stime deltas over a 2s window):
PID 89383 threads=12 -> hot thread 89403: ~100% of a core (steady), main thread ~idle
PID 126565 threads=11 -> same pattern
PID 128693 threads=13 -> same pattern
PID 148574 threads=12 -> same pattern
PID 182768 threads=14 -> same pattern
PID 187850 threads=13 -> same pattern
PID 188522 threads=12 -> same pattern
ps shows each instance accumulating hours of CPU time while sitting idle in a terminal (Sl+, attached to an active tty).- Load average with 8 idle instances: ~28 on a 16-core box. After lowering priority only (
renice +19), load dropped toward ~16 and stayed there — confirming the burn is constant background spin, not user-driven work. - The hot thread does not block on IO; it burns user+sys time in a tight loop.
- The iastudio daemons on the same machine were measured idle — crabcode was the sole CPU consumer.
Suspected cause
Looks like the TUI event-loop / render tick spins instead of parking when there is no input and nothing to redraw (crossterm event poll falling through to a busy redraw, or a worker loop missing its park/wait when the channel is empty). The v0.0.2 note "adapt event loop poll rate to reduce idle CPU" suggests this area regressed again since then.
Workaround used
renice -n 19 -p <pids> on all instances — machine stays responsive, but each session still wastes a core of idle capacity.
Request
Could you either:
- park the render/event thread when idle (e.g. blocking read with timeout, or redraw-on-dirty-only), or
- expose a knob (env var like
CRABCODE_FPS / poll interval) so multi-session users can cap it?
Happy to provide more profiling data (perf output) if useful. Thanks for the great tool!
Bug: one worker thread pegs a full core per instance, even when idle
Summary
Every running instance of crabcode keeps one single worker thread spinning at ~100% of one CPU core continuously, even when completely idle (no inference, no streaming, TUI untouched). With several sessions open this multiplies: 8 instances ≈ 8 cores burned 24/7.
Environment
Evidence
Measured via
/proc/<pid>/task/*/stat(utime+stime deltas over a 2s window):psshows each instance accumulating hours of CPU time while sitting idle in a terminal (Sl+, attached to an active tty).renice +19), load dropped toward ~16 and stayed there — confirming the burn is constant background spin, not user-driven work.Suspected cause
Looks like the TUI event-loop / render tick spins instead of parking when there is no input and nothing to redraw (crossterm event poll falling through to a busy redraw, or a worker loop missing its park/wait when the channel is empty). The v0.0.2 note "adapt event loop poll rate to reduce idle CPU" suggests this area regressed again since then.
Workaround used
renice -n 19 -p <pids>on all instances — machine stays responsive, but each session still wastes a core of idle capacity.Request
Could you either:
CRABCODE_FPS/ poll interval) so multi-session users can cap it?Happy to provide more profiling data (perf output) if useful. Thanks for the great tool!