Community
Participate
Working Groups
20050315 with all of Eclipse loaded as source When I invoke content assist on a large workspace it takes about 825 ms for the content to be resolved. My first invocation was closer to 1500 ms but I suspect class loading was involved in the number. STEPS 1) Load all of Eclipse into your workspace 2) Create a java file 3) Type the letters st in a method 4) Hit content assist Traces to follow
Created attachment 19056 [details] Trace of frst invocation
Created attachment 19057 [details] Trace of subsequent invocation
Note that the first two traces are for a class with no other projects on its build path. When I added all of the SDK to its build path the time was between 3 and 6 seconds. I will attach another trace
Created attachment 19058 [details] Trace with all of the SDK on the build path
How did you create your workspace ? Which form of the plugin projects are you using ? Which JRE are you using ? How much memory did you give to the VM ?
1) I imported all of them as source using the PDE import external plug-ins 2) See above 3) I am using the Sun 1.4.2 JRE cn142-20040915 4) No command line -XmX parameters so the VM is making its own decisions Also note this is self hosted and profiled so actual performance will be somewhat better.
What profiler did you use ? Did it switch JIT off ? I am actually surprised it answered this fast under these conditions.
I was using OptimizeIt - I'm not sure if it turns off the jit or not
Did you notice slowness with a self hosted and not profiled workspace ? I tried to reproduce the slowness with the folling test case: - create a selfhosted workspace with jdtcore inside. - add some code inside ComilationUnit#codeComplete(...) to measure completion duration. - launch it. - import all plugins as source. - wait the end of build. - open SourceType.java. - add 'st' at the end of a method. - perform code assist after 'st' several time. Completions are between 300 and 800 ms each. With only one class in the workspace, completions are between 120 and 350 ms. I suspect that optimizeIt is responsible of the slowness.
Yes - it is slower with the same workspace run directly without OptimizeIt. Not as slow (I would guess about 2 seconds as I have no tools to see actual time in this scenario) but it has a noticaeable delay. This would be a good candidate for performance instrumentation using the new PerformanceStats from Core
Ideas: - reduce index locking by only requesting a subset of them based on search scope (use job family or tag indexes as dirty). - could still use some index in memory even if dirty (need to check with Kent)
Tod - Does the slowness of code assist appear only just after a specific event like launch eclipse or import a project or checkout a project or save an editor ? In these cases Search index could be not ready and code assist look inside JavaModel instead of using Search.
The profiles I gave you were after a restart. The performance issues for the first trace likely involved indexing etc. but the others were just subsequent invocations of the same operation.
Current state: code assist is significantly faster when search indexes are ready (between 1% and 30% faster than eclipse 3.0). That's due to performance improvement of search engine.
No direct improvment has been done on Code Assist, but a lot of improvments have been done on other components used by Code Assist (search, model). Now code assist seems to have good performance (see comment 14). Reopen this bug if you find a case where code assist is too slow.
