wtfutil / wtf

The personal information dashboard for your terminal
http://wtfutil.com
Mozilla Public License 2.0
15.83k stars 804 forks source link

CPU usage increases by 100% on every save of config file #1478

Closed TheJavaGuy closed 9 months ago

TheJavaGuy commented 1 year ago

OS: macOS 12.6 (21G115) wtfutil version: a63329214c888cfbfc67c7ddcf31887c3c8a1c36 (2022-10-05T15:08:35Z)

I installed wtfutil via homebrew. I started it with custom config (e.g. wtfutil --config=/Users/ivanmilosavljevic/.config/wtf/ivan_config.yml). This custom config was just a copy of provided default config. Then I started making changes, like changing positions, width and height of modules, or adding a new module, removing a module etc. After every save of config file the CPU usage of wtfutil went up by 100% (so after 7 saves => 700%).

jkrysakowski commented 1 year ago

same here

aketawi commented 1 year ago

can confirm, same happens using Arch linux and the AUR package.

Vlad-Vargan commented 1 year ago

Same for ubuntu 22 amd64 insane CPU usage

jonhadfield commented 1 year ago

When wtf detects a change, it restarts the app, reloads the config file, and then starts watching the same file again. The problem is that the code used to monitor the config file for changes is not stopping the watching processes before the new ones start. This is evident when running strace at the time of file change; the number of PIDs running newfstatat (system call to get the status of a file) simply double each time.
To recreate, run wtf and then get the pid: ps -ef | grep wt[f]util | awk '{print $2}' now watch the rate of calls being made to check for these newfstatat calls: strace -f -p 1766386 2>&1 | grep .config at the same time, modify and then save the config file. The calls look something like this: [pid 1639797] newfstatat(AT_FDCWD, "/home/hadfielj/.config/wtf/config.yml", <unfinished ...>

The library used for the file watching (github.com/radovskyb/watcher) seems to be at fault and no longer maintained (no updates since 2019). I'm working on a fix that includes switching it out for fsnotify. Will try to get it out this week for testing.

The CPU impact isn't massively noticeable on my macbook but maxes it out on a Raspberry Pi 4, making it completely unresponsive.

edit: Had no idea how complex file watching is, e.g. https://github.com/fsnotify/fsnotify/issues/372. Possibly out of my depth on this one but will keep at it as I find the time.

huyz commented 1 year ago

Wow, my M1 macbook burned my lap. First time this has happened

macino commented 6 months ago

This is still happening. I've tested it today with version 0.43.0. One CPU core is maxed out and the fans are running wild like they never did before.