Community
Participate
Working Groups
3.3 M6 Showing the debug toolbar drop-down takes ~2 seconds in my environment, and creates ~17M of garbage (according to the heap status monitor). Profiling in YourKit shows that for 7 launch configs, it's doing 49 calls to LaunchConfiguration.exists(), which accounts for 100% of the time. The 7 exists() checks lead to 35 calls to WorkspaceRoot.findFilesForLocation(IPath), which leads to 7420 calls to FileSystemResourceManager.getFileURI(URI) and a similar number of other resource and URI operations. See attached CPU traces for details. One shows the merged callees from LaunchConfiguration.exists(), the other shows the merged callers to LaunchConfiguration.exists().
Created attachment 67728 [details] YourKit CPU traces
The slowness is only seen when the launch configs are saved to the workspace (Shared file in the Common tab). Of the 7 launch configs in my list, 5 are shared (you'll see this in the caller trace). The caller trace shows many redundant calls to exists(). If this could be reduced to 1 exists() check for each launch config, this would be sped up by a factor of 7. The number 35 comes from 5 shared launch configs * 7 exists() calls each. The fan-out from 35 to 7420 is due to the number of projects with custom filesystems in my workspace (212). I showed this to John, who is looking into possible improvements on the core resources side. Could the call to findFilesForLocation(IPath) be eliminated entirely? In the UI, it prompts for a workspace resource, not a filesystem path. Could the launch config remember that instead? If it's remembering the filesystem path instead, it seems like that would be prone to problems as well, e.g. if the project is moved to another filesystem location.
Created attachment 67820 [details] patch This reduces the calls by a factor of 10. We may be able to improve this more.
Darin, can we target this for 3.3? See also bug 174148.
Created attachment 68363 [details] updated patch
+1 speedy
speeeeeedy indeed +1, applied patch
verified
