https://github.com/apache/commons-compress/blob/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ParallelScatterZipCreator.java#L84
I'm looking at using a PriorityQueue for scheduling the tasks so the largest files get zipped first. Combined with ForkJoinPool work stealing I'm hoping this should solve the problem of less-than complete saturation towards the end of the compression run. Kristian 2015-01-12 10:29 GMT+01:00 tibor17 <tibo...@lycos.com>: > I guess every virtual machine might be configured to use only few CPU out of > let's say 16 CPU. > I am convinced "use all available CPU cores" means application Threads and > not the CPU itself. > The customer should be convinced we don't make any selection on particular > processors. > Of course Java program cannot make any guess on which processor want's to be > used. > I am sure Kristian said this because of optimizations level, so that > creating more Threads than the number of processors would not make any > significant difference in performance for this functionality. > Even ForkJoinPool is a pure pool with Java Threads - it's still the same > Thread as it was before with more fancy join-functionality for us developers > - nothing special - no direct selection of processor in Java code. > > > > ----- > BR, tibor17 > -- > View this message in context: > http://maven.40175.n5.nabble.com/Preview-release-Plexus-Archiver-multithreaded-Zip-edition-tp5822942p5823232.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
