Created attachment 143349 [details] CPU usage 100% of a single core. SUMMARY I have a modern rig. My disks are PCIE with 4 GB/s read speed. My CPU is 10900K with 20 cores. Thumbnails should generate fast but currently they don't because Gwenview doesn't take advantage of multi-core processing. STEPS TO REPRODUCE 1. Have modern hardware like Intel 10900K or AMD 5900X, and NVME 2TB/s+ disk. 2. Have a directory with hundreds of pictures that are 12-20 MP each. 3. Open the directory in thumbnail view. OBSERVED RESULT Thumbnails show up slowly, roughly at a rate of 10 thumbnails per second. IO reads are low (max at around 100 MB/s). Far from the maximum. CPU usage of Gwenview is 100% of a single core. This means thumbnail generation speed is capped by the speed of a single core. EXPECTED RESULT Use all the compute power available to Gwenview by using all available cores to generate thumbnails. SOFTWARE/OS VERSIONS N/A ADDITIONAL INFORMATION
If we did this, I suspect inevitably we'd get bug reports about the opposite thing: Gwenview taking up all your CPU power, slowing down the rest of the system, and generating too much heat.
(In reply to Nate Graham from comment #1) > If we did this, I suspect inevitably we'd get bug reports about the opposite > thing: Gwenview taking up all your CPU power, slowing down the rest of the > system, and generating too much heat. I just send a post about the EXTREMELY slow job of Gwenview before seeing this post, I'm sorry. Forgive me, but to think that others might complain about Gwenview becoming slow on "basic" computers when using multiple cores does not seem to me to be a sensible response. At present, it is impossible for me to use Gwenview or to recommend it, because it is so slow that when a friend showed me the speed of "XnView MP" (version for personal use) I had to abandon Gwenview. The best way to see how extremely slow Gwenview is is to compare it with "XnView MP" working with images in remote folders. It is unbelievable how fast "XnView MP" displays not only thumbnails, but their size, resolution, date, camera and lens, and icons related to their format, and it is not a native KDE Plasma application!!!! You can clearly see that "XnView MP" works with several threads at the same time, and does not slow down the system at all. Translated with www.DeepL.com/Translator (free version)
Thumbnail generation being too slow is a legitimate issue. However using all cores to brute-force our way through it to gain more speed may not be the best solution. Maybe the thumbnail generation algorithm is slow and can be improved to gain more speed without having to use more CPU resources. It will require some investigation.
(In reply to Nate Graham from comment #3) > Thumbnail generation being too slow is a legitimate issue. However using all > cores to brute-force our way through it to gain more speed may not be the > best solution. Maybe the thumbnail generation algorithm is slow and can be > improved to gain more speed without having to use more CPU resources. It > will require some investigation. I agree that it is quite possible that it is the reading algorithm and/or the thumbnail generation algorithm that is penalising Gwenview in this way. I gather that this problem affects the whole Plasma ecosystem in general that uses QT libraries for thumbnail generation and that properly optimising them will increase the performance and speed of thumbnail generation in general for other QT applications like Dolphin, Krusader, etc. It is also true that I don't understand how it is possible that they didn't notice this problem before, when we are talking about one of the (if not more) advanced desktops for Linux. Hopefully this problem will be corrected as soon as possible, because in the meantime those users who need optimised image management applications (and in reality any user) will have to use applications like the mentioned "XnView MP" to be able to work fluently under Linux. Thank you
*** Bug 447971 has been marked as a duplicate of this bug. ***
*** Bug 429725 has been marked as a duplicate of this bug. ***
*** Bug 481643 has been marked as a duplicate of this bug. ***
This should make things much faster, allowing parallel jobs: https://invent.kde.org/frameworks/kio/-/merge_requests/1968
In the merge request I can see, that max instances is set to 5. Is it possible to change that value as a user at runtime somehow? Or can I only change that at compile time? I am asking, because I don't what is the reason for setting this to value 5? Wouldn't it be better to have a dynamic default like "number of CPU cores - X" or something? I myself have 16 cores and 32 threads so I would like to set this to at a value of at least 10 or even more.
(In reply to Florian Dittmer from comment #9) > In the merge request I can see, that max instances is set to 5. > Is it possible to change that value as a user at runtime somehow? Or can I > only change that at compile time? > I am asking, because I don't what is the reason for setting this to value 5? > Wouldn't it be better to have a dynamic default like "number of CPU cores - > X" or something? > I myself have 16 cores and 32 threads so I would like to set this to at a > value of at least 10 or even more. We want to make it dynamic in future. For now, to get started somewhere, we decided it's best to start with small number.