* stable-6.1:
[benchmarks] Remove profiler configuration
Add SHA1 benchmark
[benchmarks] Set version of maven-compiler-plugin to 3.8.1
Fix running JMH benchmarks
Add option to allow using JDK's SHA1 implementation
Ignore IllegalStateException if JVM is already shutting down
Change-Id: Ie433c46a01a0f33848d54ecf99b30a44ca01e286
Introduce a new benchmark that shows a typical use-case
of opening a cached repository and fetching one ref from
a repository with a high number of refs.
This specific benchmark is tailored to the Gerrit use-case
of reading frequently individual refs SHA1s and by ref-name
prefix from the All-Users repository.
Include the following variables for the benchmark:
- numBranches (from 100 up to 50000)
- trustFolderStat (true or false)
- useRefTable (true or false)
The benchmark needs to be evaluated on a local high-perf SSD
and on a slower NFS network disk.
Bug: 576165
Change-Id: Ie59a87ca9f0191ff30229688e3430332e2f59a4f
We can either
- try moving the file and, in case the target directory doesn't exist,
handle the NoSuchFileException this raises to create the target
directory
- or we always first test if the target directory exists and create it
in case it is missing
On my Mac this yields
Benchmark Mode Cnt Score Error Units
FileMoveBenchmark.moveFileToExistingDir avgt 5 196.490 ± 15.194 us/op
FileMoveBenchmark.moveFileToExistingDirExists avgt 5 223.217 ± 54.816 us/op
FileMoveBenchmark.moveFileToMissingDir avgt 5 332.169 ± 43.871 us/op
FileMoveBenchmark.moveFileToMissingDirExists avgt 5 303.815 ± 137.568 us/op
This means if the target directory of the move already exists the
first strategy is faster by around 25 us/op otherwise the second one
is faster by around 30 us/op. Which one is favorable depends on the
average probability that the target directory exists in real world
scenarios.
Change-Id: I03653b408b859a796508dfa1471b36c65633534e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Results on Mac OS 10.14.6 using APFS:
Result "org.eclipse.jgit.benchmarks.LookupFileStoreBenchmark.testLookupFileStore":
44583.277 ±(99.9%) 2666.096 ns/op [Average]
(min, avg, max) = (43707.073, 44583.277, 45320.685), stdev = 692.377
CI (99.9%): [41917.181, 47249.373] (assumes normal distribution)
Secondary result
"org.eclipse.jgit.benchmarks.LookupFileStoreBenchmark.testLookupFileStore:·stack":
Stack profiler:
....[Thread state
distributions]........................................................
100.0% RUNNABLE
....[Thread state:
RUNNABLE].............................................................
42.5% 42.5% sun.nio.fs.UnixNativeDispatcher.realpath0
37.9% 37.9% sun.nio.fs.UnixNativeDispatcher.stat0
11.0% 11.0% sun.nio.fs.BsdNativeDispatcher.getfsstat
7.6% 7.6% sun.nio.fs.BsdNativeDispatcher.fsstatEntry
0.7% 0.7% sun.nio.fs.BsdNativeDispatcher.endfsstat
0.1% 0.1% sun.nio.fs.UnixPath.initOffsets
0.0% 0.0% sun.nio.fs.UnixFileAttributes.get
0.0% 0.0% java.util.zip.Inflater.inflateBytes
0.0% 0.0% sun.misc.Unsafe.compareAndSwapInt
0.0% 0.0% sun.nio.fs.BsdFileStore.findMountEntry
This shows that FS.attrCacheByPath should be useful to reduce overhead
of looking up the FileStore of a given file.
Change-Id: I7213086b42e0453f0ee149660d507dac2a4644cc
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
See [1] for JMH documentation and [2] how to use JMH in Eclipse.
The benchmarks pom currently cannot use the JGit parent pom due to an
ecj bug [3] regarding annotation processing. Hence for now do not
inherit from the JGit parent pom and copy the compiler plugin
configuration for javac from the parent pom.
After running the Maven build the benchmark can be run using Maven:
$ java -jar org.eclipse.jgit.benchmarks/target/benchmarks.jar
or in Eclipse by running the main method of the SimpleLruCacheBenchmark
class.
[1] https://openjdk.java.net/projects/code-tools/jmh/
[2] http://alblue.bandlem.com/Page/3/index.html
[3] https://eclip.se/532029
CQ: 20517
CQ: 20518
Change-Id: Idca8a9e0980f0b8a9c741c4c9e97d03c62f07c8d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Matthias Sohn