Created attachment 151693 [details] (strace file) Hello guys, I'm running Debian 11/stable and the gwenview I have is of version 20.12.3 which is like 2 years behind what it is now 😄 Today I launched it for the very first time and after leaving it idle for a while i noticed it was maxing out CPU. I look closer with strace and can see it does some repetitive kernel calls to open various thubmnail files from my home dir, which do not exist. Like it's trying to identify if there's a thumbnail exist for some image: === cut == 0.000160 openat(AT_FDCWD, "/home/pi/.cache/thumbnails/normal/c7fcf9994e28aa4446314e8d44702782.png", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 0.000370 openat(AT_FDCWD, "/home/pi/.cache/thumbnails/normal/c7fcf9994e28aa4446314e8d44702782.png.bmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 0.000117 openat(AT_FDCWD, "/home/pi/.cache/thumbnails/normal/c7fcf9994e28aa4446314e8d44702782.png.cur", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 0.000102 openat(AT_FDCWD, "/home/pi/.cache/thumbnails/normal/c7fcf9994e28aa4446314e8d44702782.png.fit", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 0.000098 openat(AT_FDCWD, "/home/pi/.cache/thumbnails/normal/c7fcf9994e28aa4446314e8d44702782.png.fits", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 0.000097 openat(AT_FDCWD, "/home/pi/.cache/thumbnails/normal/c7fcf9994e28aa4446314e8d44702782.png.gif", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 0.000141 openat(AT_FDCWD, "/home/pi/.cache/thumbnails/normal/c7fcf9994e28aa4446314e8d44702782.png.ico", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) === end of cut == And all those calls are attributed to vast majority of time that app was spending on CPU: === cut == pi@orangepi4-lts:~$ sudo strace -c -p 70014 strace: Process 70014 attached ^C strace: Process 70014 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 42.47 0.178028 11 15074 14139 openat 21.86 0.091656 25 3615 read 11.62 0.048727 8 5925 2 newfstatat 7.75 0.032476 10 3068 write 5.08 0.021315 24 862 22 faccessat 4.28 0.017959 19 945 ppoll 2.47 0.010357 11 935 close 1.37 0.005738 9 614 59 statx 1.32 0.005552 6 924 fstat 1.10 0.004626 27 168 getdents64 0.61 0.002575 9 271 ioctl 0.03 0.000109 10 10 lseek 0.01 0.000047 9 5 getuid 0.01 0.000043 8 5 geteuid 0.00 0.000012 12 1 clone 0.00 0.000000 0 2 futex ------ ----------- ----------- --------- --------- ---------------- 100.00 0.419220 12 32424 14222 total === end of cut == Attaching a raw strace log as well for the period of time when this issue was happening. I'm guessing there's no need to try to probe each and every filetype for a thumbnail. I'm 100% sure users are not configuring their thumbnails to be created in different image formats. From the user perspective the issue is like this - when you open some folder with big amount of images (in my case it was like few thousands) and leave it idle, the gwenview first maxes out CPU, then goes into SWAP then system starting to die. I would be glad if you can give me some URL for build instructions for gwenview, so I could check the same behavior in the most recent version. I do have a recent experience of building a Kate :)
A possibly relevant merge request was started @ https://invent.kde.org/graphics/gwenview/-/merge_requests/154
(In reply to Bug Janitor Service from comment #1) > A possibly relevant merge request was started @ > https://invent.kde.org/graphics/gwenview/-/merge_requests/154 That should fix the unneeded syscalls, but I'm not sure this will actually substantially reduce the CPU usage. Some profiling would help to show what the CPU is actually doing
For building Gwenview from source see https://community.kde.org/Get_Involved/development It's not really much different from Kate
Thanks a lot, Nicolas. Once that your merge is in place, I'll check the version from main.
CPU still will be used, that's for sure - but at least it will be used on purpose, for actual thumbnails generation and not for probbing filesystem :)
Found a duplucate for this bug - https://bugs.kde.org/show_bug.cgi?id=404542 I'll test the fix tomorrow and if that works, you can close both.
Git commit 408ce1e7d4bd082378c1da685d01dcd5c6bf9a60 by Bharadwaj Raju, on behalf of Nicolas Fella. Committed on 23/10/2022 at 18:50. Pushed by bharadwaj-raju into branch 'master'. Don't attempt to load a nonexistant image when creating thumbnails When given a path that doesn't exist QImage tries loading that path plus the extensions of all image formats it knows This causes unneeded syscalls We can check once whether the file exists and only attempt to load the image if we know it is there M +4 -0 lib/thumbnailprovider/thumbnailprovider.cpp https://invent.kde.org/graphics/gwenview/commit/408ce1e7d4bd082378c1da685d01dcd5c6bf9a60