unzip parallel, 3x faster than 7zip

[Jay Norwood]

On Sunday, 8 April 2012 at 13:55:21 UTC, Marco Leise wrote:
> Maybe the kernel caches writes, but synchronizes deletes? (So 
> the seek times become apparent there, and not in the writes)
> Also check the file creation flags, maybe you can hint Windows 
> to the final file size and they wont be fragmented?

My understanding is that a delete operation occurs after all the 
file handles associated with a file are closed, assuming there 
other handles were opened with file_share_delete.  I believe 
otherwise you get an error from the attempt to delete.

I'm doing some experiments with myFrag sortByName() and it 
indicates to me that there will be huge improvments in delete 
efficiency available on a hard drive if you can figure out some 
way to get the os to arrange the files and directories in LCNs in 
that byName order.  Below are the delete time from win7 rmdir on 
the same 2GB folder with and without defrag using myFrag 
sortByName().

This is win7 rmdir following  myFrag sortByName() defrag ... less 
than 7 seconds
G:\>cmd /v:on /c "echo !TIME! & rmdir /q /s tz & echo !TIME!"
  9:06:33.79
  9:06:40.47


This is the same rmdir without defrag of the folder.  2 minutes 
14 secs.
G:\>cmd /v:on /c "echo !TIME! & rmdir /q /s tz & echo !TIME!"
14:34:09.06
14:36:23.36

This is all on win7 ntfs, and I have no idea if similar gains are 
available for linux.

So, yes,  whatever tricks you can play with the win api in order 
to get it to organize the unzipped archive into this particular 
order is going to make huge improvements in the speed of delete.