Using the custom/script module with tail = true will cause the CPU to wake up 40 times a second even if there is no new output from the script.
Expected behavior:
Resources are only consumed when there is work to be done. Polybar is actually very efficient as far as CPU time goes, but all of the polling does not bode well for the battery life as it prevents the CPU from going into deeper sleep states.
Actual behavior:
CPU is woken up 40 times a second with nothing to compute.
[bar/top]
width = 100%
height = 34
background = #00000000
foreground = #ccffffff
modules-right = nothing
[module/nothing]
type = custom/script
exec = cat
tail = true
Then start powertop to monitor the CPU wakeups.
gunca@Guntars ~$ polybar -l trace top
* Loading config: /home/gunca/.config/polybar/config
- config: Current bar section: [bar/top]
* Loaded monitor eDP1 (1920x1080+0+0)
* Bar geometry: 1920x34+0+0; Borders: 0,0,0,0
- bar: Attach X event sink
- bar: Attach signal receiver
- controller: Install signal handler
- controller: Setup user-defined modules
* Starting application
- controller: Main thread id = 1
* Starting module/nothing
* Entering event loop (thread-id=1)
* module/nothing: Invoking shell command: "cat"
* Eventqueue worker (thread-id=2)
- bar: Create renderer
- renderer: Get TrueColor visual
- renderer: Allocate colormap
- renderer: Allocate output window
- renderer: Allocate window pixmaps
- renderer: Allocate graphic contexts
- renderer: Allocate alignment blocks
- renderer: Allocate cairo components
- renderer: Load fonts
* Configured DPI = 96x96
warn: No fonts specified, using fallback font "fixed"
* Loaded font "fixed" (name=Noto Sans, offset=0, file=/usr/share/fonts/noto/NotoSans-Regular.ttf)
* Bar window: 0x2400001
- bar: Reconfigure window
- bar: Set window WM_NAME
- bar: Set window _NET_WM_WINDOW_TYPE
- bar: Set window _NET_WM_STATE
- bar: Set window _NET_WM_DESKTOP
- bar: Set window _NET_WM_PID
- bar: Map window
- bar: Draw empty bar
- bar: Setup tray manager
* Disabling tray manager (reason: missing `tray-position`)
* module/nothing: Rebuilding cache
- bar: Force update
* Redrawing bar window
- bar: Received expose event
polybar -vvv: polybar 3.4.0
Features: +alsa +curl -i3 -mpd +network(libnl) +pulseaudio +xkeyboard
X extensions: +randr (+monitors) +composite +xkb +xrm +xcursor
Build type: Release
Compiler: /usr/bin/c++
Compiler flags: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Wall -Wextra -Wpedantic -O3 -DNDEBUG
Linker flags: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
This is the likely culprit https://github.com/polybar/polybar/blob/fe7dc28b07afe949ee2e0fae625e2e0d456d0185/src/modules/script.cpp#L37 though I'm not a systems programmer and plead ignorance.
I will take a look at that asap.
It might be hard to improve the situation. I have a solution but I need to modify a little bit how we stop the modules.
If one of the thread is blocked on a poll, the module can't be stopped. I'll publish my PR soon.
Thanks for looking into it - I just came to the same conclusion. As a workaround I changed the poll timeout to 3000ms and it's working OK for me. The deconstruction of the module can take that much, but I'm fine with that.
Most helpful comment
I will take a look at that asap.