Re: [BUG] unpacking zip archives horribly slow


> When I press enter in zip archive, mark some files and press f5 (copy)
> to extract them, it takes about 3 second for each file (well, on a
> 486DX4/100, but running "unzip" is much faster, so it's not
> caused just by slow cpu)
> I think the reason is in extfs/uzip - when I try to run it alone, it takes about 2 seconds to compile the script with perl and execute it. And since it is executed and terminated repeadedly for each extracted file, it's horribly slow (I read numbers like 200 bytes/second on the progress indicator)
> This is especially annoying for archives containing lot of small files,
> running unzip takes few seconds, unpacking them with mc via F5(copy)
> takes usually few minutes
> Proposed solutions:
> rewrite uzip in C, not i perl (should be quite easy, just use z-lib). This will be faster and I think someone have already done it (i can look on the web for it) but for extracting lot of small files this will fix the things only partially.
> So I think that in addition to copyin/copyout in extfs protocol there should be added something like multicopyin/multicopyout, allowing to supply a list of files to be extracted, instead of calling the binary in extfs once for each file.
> Or, even better, integrate .zip file support directly into mc (like it seems to be done with .tgz files) since .zip is quite popular format ...
> Which solution would be the most preferable? I might help with
> coding it ...

multicopyout will have ugly issues with error handling (if single file
fails, it will be "interesting" to return that info back from the
shell script...

Integrating zip into mc is certainly doable.

Completely different protocol for extfs would be probably
best. Something like "run extfs, then tell it over pipe what to
do". You may reuse some parts of fish.
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]