Even when running patch-hub in release mode, we can notice that the application consumes too much CPU for a simple TUI. I've seen occurrences where, while idling in a screen, the CPU consumption goes up to 30% (mind that in my setup I have 16 logical processors).
How to reproduce:
Launch a system monitoring tool like htop
Launch patch-hub in release mode with cargo run --release
If in htop find the process and lock it with Shift+F
Navigate through the tool and notice that there is some "unreasonable" CPU consumption
Expected behavior:
The problem resides in here, as we are rendering 60FPS. This design choice was made to avoid blocking the tool until a key event is captured. We could (1) reduce the framerate to something lower, as patch-hub surely doesn't need that many frames, or (2) eliminate this pooling, and block for each key event.
Approach 1 has the pro of reducing the CPU load (fewer frames to render per second), but, at least currently, patch-hub works the same with approach 2, while making it the most lightweight (which is what we expect from a TUI).
Description:
Even when running
patch-hubin release mode, we can notice that the application consumes too much CPU for a simple TUI. I've seen occurrences where, while idling in a screen, the CPU consumption goes up to 30% (mind that in my setup I have 16 logical processors).How to reproduce:
htoppatch-hubin release mode withcargo run --releasehtopfind the process and lock it withShift+FExpected behavior:
The problem resides in here, as we are rendering 60FPS. This design choice was made to avoid blocking the tool until a key event is captured. We could (1) reduce the framerate to something lower, as
patch-hubsurely doesn't need that many frames, or (2) eliminate this pooling, and block for each key event.Approach 1 has the pro of reducing the CPU load (fewer frames to render per second), but, at least currently,
patch-hubworks the same with approach 2, while making it the most lightweight (which is what we expect from a TUI).Screenshots
60FPS
Blocking
Setup: