Community
Participate
Working Groups
When trying to track down slowness in Eclipse, I've noticed that the DecorationScheduler is taking up quite some time. Digging down ( will attach a YourKit snapshot ) I saw that the majority of the work is done by the ContainerTreeIterator.isEntryIgnored, which in turn calls ContainerTreeIterator.isEntryIgnoredByTeamProvider for each of the Resource's parents, up til the workspace root ( or an ignored resource ): pre.. @Override public boolean isEntryIgnored() throws IOException { return super.isEntryIgnored() || isEntryIgnoredByTeamProvider(getResourceEntry().getResource()); } private boolean isEntryIgnoredByTeamProvider(IResource resource) { if (resource instanceof IWorkspaceRoot) return false; if (Team.isIgnoredHint(resource)) return true; return isEntryIgnoredByTeamProvider(resource.getParent()); } p. On average, one method call to isEntryIgnored generates 10 calls to isEntryIgnoredByTeamProvider. This is expected for me, since I'm developing using Java and Maven, which promote deep folder hierarchies. Nevertheless, I believe that a lot of unnecessary Team.isIgnoredHint calls are performed, since in the usual case - resource is not ignored - the resource tree is walked up to the workspace root each time. Tested with EGit v0.9.3-168-g69a4255 and JGit v0.9.3-224-g34962b4.
Created attachment 183665 [details] Call ratio and spent time in YourKit
The YourKit snapshot is well over the 2MB size enforced by Bugzilla, even when bzipped. I can send it by other means, if needed.
I would be very interested in this yourkit outcomes. We do have perfomance problems in the iterators and are investigating currently multiple use-cases where this happens (E.g. the commit dialog performance). Since gathering performance measurements is always hard work (can't count how many ours I spent already on TPTP or adding and removing time-measuring code into the code) I would like to see what you got.
What do you suggest for a 22 MB file?
You can try http://dl.dropbox.com/u/11860058/org.eclipse.equinox.launcher_1.1.0.v20100507-2010-11-23.snapshot.bz2 .
thanks, I got the file from dropbox
http://dl.dropbox.com/u/11860058/org.eclipse.equinox.launcher_1.1.0.v20100507-2010-12-02.snapshot.bz2 contains a Snapshot of Eclipse's startup until it is 'usable'. EGit resource decoration take up roughly 25% of all the spent time - counted across all threads.
Phillip, you did a lot of improvements on decorations and also on the initial decoration. Do you have any updates on the state of this?
Hi Robert! We have implemented several improvements to the decorators in EGit. As this bug was filed a long time ago, it would be good to know, if you already re-tested your scenario with the latest version of EGit and if you still see the same or a similar slowness. Thanks, Philipp
Hi Phillip. I will try to reassess this scenario in the coming days and let you know.
Hi Phillip, I've managed to capture a snapshot of the decorator execution times when Eclipse was getting really slugish. This was with {j,e}git 0.12.1, The file is uploaded at http://dl.dropbox.com/u/3160732/egit-0.12-decorator.snapshot.gz It clearly shows that: * the GitDecoratorJob takes up a lot of CPU time ( 41%, which becomes roughly 66% once we exclude the time spent by WorkerPool.sleep ) * org.eclipse.egit.core.ContainerTreeIterator.isEntryIgnored() is at root of a hotspot using org.eclipse.team.internal.core.StringMatcher.textPosIn(String, int, int, String) via org.eclipse.team.core.Team.isIgnoredHint(IResource) ( the original report of this bug ) So in my opinion this report is still valid.
Patch at https://git.eclipse.org/r/7297 Completely untested.
I imported the project set and it takes about 8 sec before the decorator vanishes from the progress menu. It takes about three secs before it appears so it last five seconds, nowhere near several minutes. The patch has no effect on timing.
I tried on Mac using a repository with 60000 files in 7000 directories and couldn't find a significant speedup with this change.
So we could just ignore this since it has no practical effect, or keep the patch as a matter of principle, i.e. avoid the extra calls for free. I don't even know if it's ok to just check the Team.isIgnoredEntry on just the leafs. Maybe it has to be called on all levels. If nobody knows we'll abandon the patch and close this issue as invalid.
I'm going to benchmark this on two different systems with largish repos next week to see if I see any improvements. I assume you're all running on master so I'll install a nightly.
(In reply to comment #16) > I'm going to benchmark this on two different systems with largish repos next > week to see if I see any improvements. I assume you're all running on master > so I'll install a nightly. It's just a patch in gerrit, i.e. not in the nightly build. Building it with maven is pretty easy though.
Abandoned/Fixed depending on interpretion of 359052
