I am using EGit on fairly large and complex set of Java projects (more than a million line of code) and a decade worth of history.
Here I am facing serious performance issues with EGit, as even small one line change in the Java file causes EGit to re-index for couple of minutes which is slowing the entire system.
Indeed, even git command line is bit slow as “git status” takes around a minute from command line, but I can live with this performance issue, & EGit commit dialog slowness issue (link). As I can use git command line to commit, and update, but I don’t want to tradeoff my Eclipse performance as that does affect productivity.
The following is what I have tried by doing Googling and asking people around:
- Added all classes folder in the exclude file. Indeed tried putting the classes folderin .gitignore as well for time being.
- Gave Egit enough time to finish indexing by keeping the machine ON for a day.
- Git staging, history and all other Eclipses views are closed in the Eclipse workbench while doing development.
- Did “git gc” – It made difference on the command line performance, but hardly any difference for EGit.
- Unchecked Label decorator for Git. Preferences -> General -> Appearance -> Label Decorations.
- Removed the cygwin from path, as read somewhere in the forum that JGit might be using cygwin for path conversion.
- Increased window cache from 10 to 70m in Eclipse (Preferences -> Team -> Git -> window cache).
PS: Git repository is pointing to svn remote repository. Also, I am git newbie so might have made some mistake in setup, so please feel free to point out anything.
Here is my system information, I don’t have much fancy hardware specs, but some RAM to spare (8GB).
- git-gui version 0.16 GITGUID
- git version: 1.7.10.mysysgit.1
- JDK 1.6_025
- Eclipse version: 3.7.2 Java EE version with parameters -Xms1536m -Xmx1536m
- EGit: 1.3.0.201202151440
- Windows 7 Processor: Core 2 Duo 2.6GHZ
That is the problem between CVCS (Centralized VCS) and DVCS (Distributed) VCS:
I suspect lots of repos might perform better than one giant Git repo. Otherwise, synchronization issues start happening, like in bug 323839.
But that means managing the (simplified) synchronization between Git repos and the one SVN repo manually, through an SVN workspace from which you are copying from to yourGit repos, or to which you are copying Git repos new evolutions back to the SVN workspace to commit in.