Created attachment 128844 [details] screenshot SUMMARY archive.so process causes high cpu usage and slows down the computer while Dolphin opens an archive as folder. Got the same result with tar.gz, zip and 7z formats. STEPS TO REPRODUCE 1. enable "Open archives as folder" in "Navigation" section of Dolphin settings 2. open an archive (tar.gz, zip or 7z) with Dolphin 3. OBSERVED RESULT While the status bar of Dolphin says "Loading folder...", archve.so process causes high cpu usage and slows down the computer. My screenshot shows the result while Dolphin opens a tar.gz archive containing 928 files (almost all jpgs) and 23 folders. EXPECTED RESULT normal cpu usage SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.19.80 KDE Frameworks Version: 5.71.0 Qt Version: 5.14.2 Kernel Version: 5.3.0-45-generic OS Type: 64-bit Processors: 4 × Intel® Core™ i3-3110M CPU @ 2.40GHz Memory: 7,7 GiB of RAM
Currently the process that causes high cpu usage is called kioslave5. CPU usage is higher with 7zip archives. Operating System: Arch Linux KDE Plasma Version: 5.22.90 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Graphics Platform: Wayland
The report isn't exactly great as it's mixing together multiple issues, some not even really KDE related, but some could be surely improved. Skipping zip as I don't tend to encounter particularly large zip files and it seems to be left behind in the "compression race", so will address only the other two. Tar: Bad news here, this is unlikely to be ever the format you'll quickly browse as it doesn't have a file index, so the whole archive needs to be scanned AND in the case of tar.gz even uncompressed which is going to be a whole lot of work just to list files. This is unlikely to get any better, attempts to introduce a file index to the tar format didn't seem to succeed, so the mind boggling part for me is that we still didn't move on to a different format. 7z: Couldn't test with Dolphin specifically as it's not into opening the test file, and stuffing it into the URL gets me a "Could not open the file, probably due to an unsupported file format." message with "sevenz:" getting prepended to the URL. Krusader and Ark however shows something surprising, the external 7z executable is used to get the WHOLE file list. Apparently that's not just I/O intensive due to being a wasteful strategy, but it surely pegs a CPU core for a while. Not really sure why isn't the k7zip implementation of karchive being used, but looking at K7Zip::openArchive I'm not sure it would be faster. This could be definitely improved. In this case kioslave5 should only show up as the CPU hog if K7Zip would be used for listing which isn't the case for me, I'm seeing the 7z process which is used to list the contents. Looking at the bug being assigned to kio-extras, there may be a tricky problem here with 7z: - If K7Zip browsing is slow, then that should belong there. I'm not sure if the whole file list really needs to be processed initially, but even ignoring that the code is surely not optimized to be able to deal with a whole lot of files. Can't compare right now, but in line with the Bug #457906 mention I can say that Total Commander makes 7z browsing quite fast. - The external 7z execution may not belong to kio-extras, that's likely done by the file/archive managers individually, at least I've found Krusader doing that.