Community
Participate
Working Groups
It takes a significant amount of time to find markers as it currently requires a taversal of the entire resource tree. If it turns out that markers are relatively few and sparse the addition of a "marker count" may avoid taversing areas of the tree where we know there are no markers.
*** Bug 7460 has been marked as a duplicate of this bug. ***
Closing for now but will consider at end of cycle as part of performance work (time permitting) or will investigate post 2.0.
Reopening for investigation.
Maintaining a marker count would help. Also, recursiveFindMarkers uses getResourceInfo and getChildren, resulting in many lookups. Recursing over the delta data tree directly would be much more efficient (would need to ensure latest tree is the complete representation first). In my self-hosting workspace (org.eclipse.jface* and org.eclipse.ui* in source, and the rest as binaries), opening the Bookmarks view generated: - about 800K of garbage (mostly Paths) - ~3500 calls to Workspace.recursiveFindMarkers and getResourceInfo - ~25000 calls to AbstractDataTreeNode.childAtOrNull - ~30000 calls to AbstractDataTreeNode.indexOfChild - ~97000 calls to String.compareTo About 3/4 of the time to open the bookmarks view was in findMarkers (2500ms on my laptop under OptimizeIt). This is a lot of work to determine that there are 0 bookmarks <g>.
After discussing with NE, some thoughts. - a count could be kept for each resource which represents the number of markers on it and its children - a value of -1 would mean "don't know" and we'd have to re-calculate - -1 could be the default on save so it would be re-calculated the first time each session?
Created attachment 2643 [details] switching to java perspective on a bug workspace i took the 'big workspace' from core website here's the profile of the first opening of the java perspective 37% of time is spent in Resource.findMarkers()
Created attachment 2644 [details] startup of big workspace Resource.findMarkers takes 41% of startup time on a big workspace (find 'Resource.findMarkers' in the attached profile) we must either acknowledge that it's slow and not call it so frequently or fix the slowness
Adam, any idea on the number of times findMarkers is invoked? As an extra data point, I ran a "findMarkers" benchmark on a running "big workspace" (74,409 resources, 812 markers). The average time for a single findMarkers call in the workspace root takes 190ms on my machine. I don't deny there are opportunities to improve this, but it would be interesting to see how many times it is called on startup.
no idea, sorry - but the number you gave suggests that it must be thousands of times. we may need to call it less often instead of making it cheaper. or provide a different model altogether
that might be the biggest gain on startup performance improvement. so it might be worth investigating.
I have tweaked the findMarkers implementation for roughly a 4x improvement. On my computer the benchmark went from 190ms to 49ms. However, there are definitely some opportunities to reduce the number of invocations of findMarkers. I have entered bug 27764 for further JDT investigation of the number of times findMarkers is called. I have included in that bug report some details of my initial investigation.
*** Bug 12618 has been marked as a duplicate of this bug. ***
Released fix to HEAD. Finding markers on a large workspace (74,409 resources) now takes 16ms for a total speedup of 12x over the original result. I have created bug 27948 to investigate exposing the fast tree traversal infrastructure that was used as general API. Note to clients: this does NOT mean you can now call findMarkers twelve times as often <g>.
did any of that speedup find its way to 20021210?
Nope. Next build. It's now in HEAD if you want to try it out.
works really great - thanks
