https://bugs.kde.org/show_bug.cgi?id=422142
Pedro V <voidpointertonull+bugskde...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |CONFIRMED CC| |voidpointertonull+bugskdeor | |g...@gmail.com Ever confirmed|0 |1 --- Comment #2 from Pedro V <voidpointertonull+bugskde...@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.