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>

Change-Id: Iad0bcc01ada4252e9ab4f60d4375f98f084f6a5f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

This is the format given by the Eclipse legal doc generator [1].

[1] https://www.eclipse.org/projects/tools/documentation.php?id=technology.jgit

Bug: 548298
Change-Id: I8d8cabc998ba1b083e3f0906a8d558d391ffb6c4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Change-Id: Ic02f32fb882602e573f34d0a38d850f43aadf7ba
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Change-Id: I953fd8b6b9743b0b9cada244331253eb2121784d
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>