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.

Reply via email to