No NIO. The problem is the ZipArchiveOutputStream in commons compress which is already suffering from a bit of an overload. With the changes I made to ZipArchiveOutputStream you could probably try to make a patch; it'd be interesting to see what kind of effect it would have. Be sure to make your patch as small and clean as possible if it's going to commons :) (And there's a profile with IT's there too :)
I somehow suspect that the mix of small computations and quite small blocks of IO is the main reason this algorithm is no faster. It writes about 250MB/s on my MBP SSD right now in the "gather" phase. Kristain 2015-01-10 19:55 GMT+01:00 Tibor Digana <tibordig...@apache.org>: > Hi Kristian, > Are you using NIO for writing big chunks? > Several years ago I made NIO1 measurements. I found that using 256KB > DirectByteBuffe on Win together with MappedByteBuffer/RandomAccessFile on > very large files 1GB got terribly fast throughput 400MB/s on ordinal hard > drive however the flush/close operation was obviously slow. So this DMA on > mapped memory really gains the performance. > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Preview-release-Plexus-Archiver-multithreaded-Zip-edition-tp5822942p5823032.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
