Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] insertUnpackedObject() perf regression: j.nio.file.Files.exists() 15x slower than

----- Ursprungligt meddelande -----
> Från: "Alex Blewitt" <alex.blewitt@xxxxxxxxx>
> Till: "Roberto Tyley" <roberto.tyley@xxxxxxxxx>
> Kopia: jgit-dev@xxxxxxxxxxx, "robin rosenberg" <robin.rosenberg@xxxxxxxxxx>, "matthias sohn" <matthias.sohn@xxxxxxx>,
> "christian halstrick" <christian.halstrick@xxxxxxx>
> Skickat: torsdag, 27 aug 2015 19:43:57
> Ämne: Re: [jgit-dev] insertUnpackedObject() perf regression: j.nio.file.Files.exists() 15x slower than
> If you have a gist or a JMH harness for performing tests I'm happy to report
> back timings for Windows and OSX.
> Alex
> Sent from my iPhat 6
> > On 27 Aug 2015, at 18:38, Roberto Tyley <roberto.tyley@xxxxxxxxx> wrote:
> > 
> > While updating the BFG Repo-Cleaner to JGit 4.0, I was surprised to see a
> > consistent performance regression on clean-large-repo benchmarks (/dev/shm
> > on Ubuntu 15.04, OpenJDK 1.8.0_45). Total run time had increased by ~10%.
> > After some fairly chunky automated git-bisecting, I traced the regression
> > to this change:

I noted a performance penalty, but at the time of introducing symlink support,
it was possible to disable the Java 7 extensions. I don't think it was much
discussed at the time.

> > Aside from performance, I'm not sure if there was any other strong
> > motivation for using j.nio.file.Files.exists(). It's called with
> > LinkOption.NOFOLLOW_LINKS, which means that when checking a symbolic link,
> > it will return true so long as the symbolic link is there, regardless of
> > whether the link points to an existing file. This differs from
> >, which does follow the link, and returns false if the
> > underlying file is not present. Is the NIO behavior useful?

Yes, the behavior is useful and very much intentional, as the commit message
says. Tracking symlinks is not dependent on whether the target exists or not. 
Git tracks the content of the symlink as if it was a text file, but with a
different file mode.

> > Obviously, my preference would be to remove use of the NIO call. I'm
> > inclined to think it could be removed everywhere, from both FS_POSIX &
> > FS_Win32, but at the very least from
> > ObjectDirectory.insertUnpackedObject().

Maybe we should make exceptions for (some) internal paths. The current
behavior probably only (mostly?) makes sense in the working directory, so we'd need
two exists() methods in FS.

-- robin

Back to the top