One of the motivations back then is to speed up the performance of accessing those entries, means you don't have to deflate/inflate those new/updated entries during the lifetime of that zipfilesystem. Those updated entries only get compressed when go to storage. So the regression is more like a trade off of performance of different usages. (it also simplifies the logic on handing different types of entries ...) One idea I experimented long time ago for jartool is to concurrently write out entries when need compression ... it does gain some performance improvement on multi-cores, but not lots, as it ends up coming back to the main thread to write out to the underlying filesystem. -Sherman On 4/16/19 5:21 AM, Claes Redestad wrote:
Both before and after this regression, it seems the default behavior is not to use a temporary file (until ZFS.sync(), which writes to a temp file and then moves it in place, but that's different from what happens with the useTempFile option enabled). Instead entries (and the backing zip file system) are kept in-memory.
The cause of the issue here is instead that no deflation happens until sync(), even when writing to entries in-memory. Previously, the deflation happened eagerly, then the result of that was copied into the zip file during sync().
I've written a proof-of-concept patch that restores the behavior of eagerly compressing entries when the method is METHOD_DEFLATED and the target is to store byte[]s in-memory (the default scenario):
http://cr.openjdk.java.net/~redestad/scratch/zfs.eager_deflation.00/
This restores performance of parallel zip to that of 11.0.2 for the default case. It still has a similar regression for the case where useTempFile is enabled, but that should be easily addressed if this looks like a way forward?
(I've not yet created a bug as I got too caught up in trying to figure out what was going on here...)
Thanks!
/Claes
On 2019-04-16 09:29, Alan Bateman wrote:
On 15/04/2019 14:32, Lennart Börjeson wrote:
:
Previously, the deflation was done when in the call to Files.copy, thus executed in parallel, and the final ZipFileSystem.close() didn't do anything much.
Can you submit a bug? When creating/updating a zip file with zipfs then the closing the file system creates the zip file. Someone needs to check but it may have been that the temporary files (on the file system hosting the zip file) were deflated when writing (which is surprising but may have been the case).
-Alan