I'm running a small Bash script on an AMD Ryzen 7 7800X3D that polls Hyprland every 0.5 seconds, collects information about the active workspace and open windows, sorts the windows by position, maps their classes to icons, and outputs JSON for Waybar. I expected the script to be nearly idle, but it consistently uses around 1–2% CPU. I'm new to scripting, so I'd like to understand where the cost comes from and whether this level of usage is normal. The script contains many pipelines, command substitutions, loops, and external utilities such as grep, cut, awk, paste, column, sort, cat, and hyprctl.
5 Answers
A 0.5-second polling interval means the entire pipeline runs twice per second, including the nested loops. That is fairly frequent for a shell script. If the display can tolerate it, increasing the interval would lower CPU use immediately. An even better design would be to update only when Hyprland reports an event or when the relevant window state changes, rather than rebuilding everything on every timer tick.
You can avoid several unnecessary external commands with Bash pattern matching. For example, this pipeline can be replaced with a direct comparison: [[ "${final[$i]}" == *"$active_window"* ]]. Similarly, awk can often replace combinations of grep, cut, tr, and sed, while Bash parameter expansion can handle simple prefix, suffix, and substring operations. Also, you do not need echo inside command substitutions when the value is already available.
The CPU usage is normal for this implementation. The machine is fast, but repeatedly spawning dozens of short-lived processes still creates measurable overhead. The percentage is not dangerous; it mostly indicates that the script is doing much more work per update than its size suggests. Capture the output of hyprctl once per iteration, parse it in one tool or in Bash, and call activewindow only when necessary.
The biggest cost is probably process creation. Every external command in a pipeline starts another process, and this happens repeatedly every half second. The script launches hyprctl several times per iteration, then runs many grep, cut, awk, tr, paste, column, sort, cat, and echo commands. Command substitutions such as $(...) and pipelines add even more process overhead. Bash can handle much of the string matching and splitting itself, which would reduce the number of processes substantially.
The nested active-window loop is another inefficiency: active_window is recalculated once for every item in final, even though it does not change during that loop. Move that command before the loop, then compare each item against the saved value. That alone removes repeated hyprctl and parsing calls whenever multiple windows are displayed.
That makes sense. I was mainly trying to keep the display responsive, since this feeds a taskbar and should update quickly.