Community
Participate
Working Groups
Created attachment 175953 [details] backtraces.tar.bz2 CDT performs a lot of location -> resource mapping. It does this before a build during dependency calculation. It appears that this is very expensive when the project contains links due to non-optimal re-calculation / resolution of the linked resource roots. For every location to search, FileSystemResourceManager#allPathsForLocationNonCanonical, iterates over every link in every project, resolving it to an URI. It then checks whether the location is relative to the URI. This seems to be very expensive -- can it be cached? In the attach tar.bz2 you can see we got a VM backtrace every 1-2 seconds. 30s or so was spent resolving dependencies using findFilesForLocation. Almost every backtraces was in: ProjectPathVariableManager.resolveURI(ProjectPathVariableManager.java:286) I'll try to add some better intelligence to the CDT end, but if this is very poorly performant, can a cache be added to the ProjectPathVariableManager?
Yes, we've run into that same problem, I think there's some lookup that the core.resources plugin should be able to do with the AliasManager. I'll look into it.
Created attachment 176470 [details] Fix Here's a fix for the find[Files | Containers]ForLocation[URI] methods so that the AliasManager is used. It improves the performance of those methods by several order of magnitude, basically transforming the algorithm into a simple lookup in a Hashtable where before it had to iterate through every single linked resource in the workspace (and resolve every single one). In my example, it improved the performance so a single call went from 3400 ms to 8 ms. There's still an edge case where if the user has an custom EFS project that contains linked resources, the performance optimization won't apply, since the AliasManager won't help resolving the file store with the custom scheme. In the overwhelming number of use-cases, though, it will apply.
John, can you review it please?
(In reply to comment #3) > John, can you review it please? This fix looks good to me. Feel free to release. I guess this was unlikely to be a problem in that past since links had to be created manually so they typically didn't appear in large numbers. Today, it is easy for a user to quickly create hundreds of links, so this kind of bottleneck easily comes up and is worth optimizing.
Thanks John, now fixed on head.
*** Bug 323465 has been marked as a duplicate of this bug. ***
