Am 2020-08-16 um 06:40 schrieb STEFAN REICH:
Hi there!
I am working on a very large code base, and build performance issues made me
look at the maven-resolver source code. In terms of File usages, there are a
lot of InputStreams being copied around using ByteBuffer, instead of using
FileChannel.transferTo. Affected classes are DefaultFileProcessor,
ChecksumCalculator, WagonTransporter, AbstractTransporter and potentially more.
Was it a conscious decision to use this pattern over the more efficient
transferTo? Would you accept a PR with more modern NIO API that still works
with JDK 7?
Hi Stefan,
I have been working on Resolver for the last couple of releases. Also on
Wagon -- which goes hand in hand with Resolver. I don't think that there
was a decision to go a suboptimal route. No one just stood up to make it
better.
Please start with Wagon first, because Resolver sits on top of Wagon
which is low level.
Here are the throughput results from a JMH benchmark, copying a 22MB file
around using the pattern currently used in maven, and transferTo, as measured
on macOS with JDK 11 on an SSD.
Result "MyBenchmark.resolverCopy":
291.362 ±(99.9%) 5.443 ops/s [Average]
(min, avg, max) = (276.923, 291.362, 302.911), stdev = 7.266
CI (99.9%): [285.919, 296.804] (assumes normal distribution)
Result "MyBenchmark.transferTo":
325.188 ±(99.9%) 8.838 ops/s [Average]
(min, avg, max) = (306.978, 325.188, 355.784), stdev = 11.799
CI (99.9%): [316.350, 334.026] (assumes normal distribution)
Please provide your clean room tests, I have four different operating
systems and JDKs to test.
I will happily accept every PR which makes Resolver and Wagon better as
long as the PRs are logically decoupled and wellreasoned.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
