[egit-dev] Bug 456996: EGit performance poor when home directory on a ne

[Thomas Wolf <thomas.wolf@xxxxxxxxxx>]

I've pushed a series of changes working towards improving EGit performance
when access to the git user config is slow. One user has reported actual
execution times for FileUtils.getAttributes() on the user config when it
is on a network share: 30ms on average, maximum 80ms.

With such access times, EGit performance plummets. The immediate cause is
that EGit still checks thousands of times whether the git user config might
have been modified on disk. Most of these checks are on background threads
in decorators and index diff calculations, and with 30ms per getAttributes()
call for the user config, it takes ages until decorators update or the
git staging view (or other views) react to changes.

This is in particular a problem for Windows users in corporate environments
where the home directory often is on a share, i.e., a remote disk. Changing
the "home directory" to some other directory on a local disk just for
Eclipse/EGit by changing environment variables is not always an option; in
fact, in such corporate environments, users may not even have the rights
to change these environment variables. It would also mean that git-for-windows
would use the normal home, while EGit would use a different home, and the
user would have to duplicate or link at least his user git config and perhaps
his ~/.ssh folder to make them both behave consistently.

These changes reduce the number of accesses to the git user config file
quite a bit:

152108[1] Close repositories when they are no longer referenced

  Is a prerequisite for 152111; the fourth change below.
  
152109[2] Decorators: cache more repository state

  Similar to what we did for handler enablement calculations in
  https://git.eclipse.org/r/#/c/148656/ , but the cache invalidation is
  triggered differently.

152110[3] Cache the repository config

  Don't re-check during some user-defined scope per thread encompassing
  one or several git operations. If the git config changed in the middle
  of some logical unit of work, results are likely in an inconsistent
  state anyway if we picked up the change (part based on config state
  before the change, part based on state after the change). So check only
  once at the beginning, then use cached values until the end of the unit
  of work.
  
152111[4] Use cached repositories for submodules

  Depends on JGit change 151660.[5] Also use the caching from 152110 for
  submodule diffs, and make sure JGit uses the Repository instances from
  EGit's repository cache for submodules.
  
I'd like to get this into EGit 5.6.0 if possible, but that means that it
would need to be reviewed and merged fairly soon, including the JGit
change.

I don't want to merge this too close to the ramp-down or release date; I
want enough beta-test time for EGit nightly users to catch potential
drawbacks before the release.

[1] https://git.eclipse.org/r/#/c/152108/
[2] https://git.eclipse.org/r/#/c/152109/
[3] https://git.eclipse.org/r/#/c/152110/
[4] https://git.eclipse.org/r/#/c/152111/
[5] https://git.eclipse.org/r/#/c/151660/