Bug 146843 - Rename a method is slow when using a big workspace
Summary: Rename a method is slow when using a big workspace
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P2 major (vote)
Target Milestone: 3.2.1   Edit
Assignee: John Arthorne CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2006-06-13 11:08 EDT by David Audel CLA
Modified: 2006-07-10 14:34 EDT (History)
1 user (show)

See Also:

Attachments
profiling result (18.25 KB, application/x-zip-compressed)
2006-06-13 11:08 EDT, David Audel CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Audel CLA 2006-06-13 11:08:19 EDT 
build 3.2RC7

I have a workspace with more than 1800 plugin projects as binary inside. This workspace contains the plugin org.eclipse.jdt.core as source.
The renaming of org.eclipse.jdt.internal.compiler.batch.Main#addNewEntry(...) with the refactoring action (Refactor>Rename )is very slow (more than 4 minutes).

I profiled this test case and i noticed that 99% of the time is spend inside WorkspaceeRoot#getProject(String).

The problem occured only the first time i tried to refactor the method. when i tried to rename the method a second time, the refactoring wasn't slow.

I will attach the result the profiling.
Comment 1 David Audel CLA 2006-06-13 11:08:52 EDT 
Created attachment 44275 [details]
profiling result
Comment 2 John Arthorne CLA 2006-06-13 11:28:29 EDT 
I was worried about this code because I put in a late fix for bug 138737.  I didn't want to add synchronization because I am optimizing for subsequent calls to getProject().  Four minutes to initialize this cache is surprising.  I will investigate.
Comment 3 John Arthorne CLA 2006-06-13 11:34:12 EDT 
I did a quick test and I can reproduce the bottle neck.  This snippet took 103 seconds to run on my machine:

IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
for (int i = 0; i < 2000; i++)
	root.getProject(Integer.toString(i));
Comment 4 John Arthorne CLA 2006-06-13 11:53:42 EDT 
After doing some benchmarks I have opted to use a synchronized HashMap.  The performance is only slightly slower than an unsynchronized map.  The snippet in comment #3 now runs in about 30ms.  I have released this fix to HEAD and will contribute to the 3.2.1 stream when available.

Thanks David, good catch!
Comment 5 David Audel CLA 2006-06-13 12:23:21 EDT 
I tested with HEAD and my test case take around 10 sec now. Good!
Comment 6 John Arthorne CLA 2006-07-10 14:34:39 EDT 
Fix released to 3_2_maintenance stream for next 3.2.1 build.