SUMMARY When a folder with many files is opened within Dolphin and many files are modified, Dolphin uses 100% of a CPU core for a very long time (forever?). Dolphin is responding though. The problem stops when the folder is left. STEPS TO REPRODUCE 1. create a folder with a thousand empty files 2. open this folder with Dolphin 3. modify all the files with `touch *` OBSERVED RESULT Dolphin uses 100% CPU, and does not appear to stop (or maybe after a very long time). EXPECTED RESULT CPU usage should rise only for a small amount of time, if at all. SOFTWARE/OS VERSIONS Linux/KDE Plasma: NixOS/21.11pre KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.81.0 Qt Version: 5.15.2 Kernel Version: 5.10.48 ADDITIONAL INFORMATION I think that when multiple modification events reach Dolphin, it process every single events, even when they are redundant. If that is the case, a possible fix would be to ignore such events if there is already a modification event in the event queue.
So to test this one, it's easiest to just use bash's brace expansion: * touch testfile{0001..1000} * touch testfile{00001..10000} Is this still reproducible for you with current Plasma? I can't reproduce this one. I had to create 10,000 files before it would reach 90% CPU on my machine, and it stops after a moment.
(In reply to Thiago Sueto from comment #1) > Is this still reproducible for you with current Plasma? I can't reproduce > this one. I had to create 10,000 files before it would reach 90% CPU on my > machine, and it stops after a moment. That what it looked like for me as well (Neon). Checked to see if it might be different on NixOS (Dolphin 21.08.3) and that also seemed well behaved. NixOS is like... Wow...
Yes, I still have the bug. To be noted that the bug does not seem to appear at the file creation (even creating 10 000 files in one go), but at the update of the files. Here are the version I am now running: Dolphin: 21.12.2 Linux/KDE Plasma: NixOS/22.05pre KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.3 Kernel Version: 5.15.26
(In reply to lemaitre from comment #3) > ... To be noted that the bug does not seem to appear at the file creation (even > creating 10 000 files in one go), but at the update of the files ... I noticed a difference between running touch testfile{00001..10000} a first time and repeating it. Dolphin worked a little harder but it was still just a second or so of high CPU. Baloo spent a while catching up with changes and baloo_file_extractor had a look at the "touched" files (in batches of 40). Nothing excessive though... Could there be an issue with large numbers of thumbnails? (How big is .cache/thumbnails/normal?)
(In reply to tagwerk19 from comment #4) > (In reply to lemaitre from comment #3) > > ... To be noted that the bug does not seem to appear at the file creation (even > > creating 10 000 files in one go), but at the update of the files ... > I noticed a difference between running > > touch testfile{00001..10000} > > a first time and repeating it. Dolphin worked a little harder but it was > still just a second or so of high CPU. > > Baloo spent a while catching up with changes and baloo_file_extractor had a > look at the "touched" files (in batches of 40). Nothing excessive though... > > Could there be an issue with large numbers of thumbnails? (How big is > .cache/thumbnails/normal?) I disabled baloo, because it was too power hungry. The process that eats the CPU is dolphin, its main thread to be precise. Indeed, the .cache/thumbnails/normal was huge, more than 3 GB. So I deleted its content. It seemed have made a difference, but only if I don't refresh dolphin window. But if I open a folder with many files, refresh it with F5, and then touch every file from the terminal, I end up in the same high cpu load case as before. The .cache/thumbnails/normal grew to 17MB and stopped there, so no alarm on this side. As a sidenote, with 10'000 empty files in the folder, the refresh takes a few seconds.
(In reply to lemaitre from comment #5) > ... the .cache/thumbnails/normal was huge, more than 3 GB. So I deleted > its content. It seemed have made a difference, but only if I don't refresh > dolphin window > > But if I open a folder with many files, refresh it with F5, and then touch > every file from the terminal, I end up in the same high cpu load case as > before. The .cache/thumbnails/normal grew to 17MB and stopped there, so no > alarm on this side. I think, if you touch a file, Dolphin and thumbnail.so recreates the thumbnail; it doesn't know that the content has not changed. If the thumbnail is recreated, Dolphin reloads it. Can be that that's loads of work... > As a sidenote, with 10'000 empty files in the folder, the refresh takes a > few seconds. It would be interesting to know if Dolphin knows it can skip looking for thumbnails of empty files. I assume you are not on an HDD...
(In reply to tagwerk19 from comment #6) > I think, if you touch a file, Dolphin and thumbnail.so recreates the > thumbnail; it doesn't know that the content has not changed. If the > thumbnail is recreated, Dolphin reloads it. Can be that that's loads of > work... I'm sure that's a lot of work, but I can stay hours with dolphin eating a full cpu. I was thinking maybe it is because dolphin tries to process all files whenever a single file is updated, but it does not seem to be the case, as touching few files does not trigger high CPU usage even for a short period of time. I am now more thinking about an infinite loop. (In reply to tagwerk19 from comment #6) > It would be interesting to know if Dolphin knows it can skip looking for > thumbnails of empty files. I assume you are not on an HDD... The bug has nothing to do with empty files. I also have the bug with images, but it is easier to reproduce the bug with empty files. You assumed correctly: I have an NVME SSD.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Oh, I missed the notification for ticket closure. Just to sum up: - Having a high number of files within a folder alone does not trigger the bug - Touching a few files in the big folder does not trigger the bug - Touching all files (a few thousands) with `touch *` DOES trigger the bug - The bug is not about empty files, it also happens with images - When I exit the folder, the CPU consumption goes down back to zero - Purging the thumbnail cache did not solve the bug