Bug 6866 - Code-Assist (ctrl+space) to slow with jre-src
Summary: Code-Assist (ctrl+space) to slow with jre-src
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows NT
: P1 normal (vote)
Target Milestone: 2.0 M2   Edit
Assignee: David Audel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 11272 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-12-12 12:48 EST by Martin Möbius CLA
Modified: 2002-03-20 11:35 EST (History)
2 users (show)

See Also:

Attachments
optimize it trace (79.85 KB, text/html)
2001-12-14 06:57 EST, Erich Gamma 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 Martin Möbius CLA 2001-12-12 12:48:49 EST 
If the source of the jre is assigned, the code-assist is very slow .
Especially at larger classes like JTable. So slow, i delete the src entry in 
jre-settings to get rid off the very nice javadoc tooltips.
If it's not possible to make it faster, it would be usefull to have the option 
to turn off the javadoc tooltip, and leave the source in jre-setting for 
debugging.
I'm using a p2-233 with 256MB.
Version 20011206.
Comment 1 Erich Gamma CLA 2001-12-13 04:13:31 EST 
problem confirmed. In the JTable scenario below it takes 1s without source 
attachment and 6s+ with source attachment. The JavaDoc extraction kicks in 
after the proposals are computed and after the pop-up shows up. I don't think 
it is the culprit.

Before perf tracing in the UI Philippe can you pls confirm that the proposal 
computation for a binary class with source attachment is as fast as proposal 
computation without source attachment.
Comment 2 Philipe Mulet CLA 2001-12-13 08:00:22 EST 
If we have source attached, then it might take longer to extract parameter 
names (need to parse attached sources to find them).
Comment 3 Erich Gamma CLA 2001-12-14 06:56:39 EST 
The attached trace shows that 80% of the time are spent in the code completion 
engine. Moving to core

The scenario is 
main() {
   JTable table;
   table.<code assist>
Comment 4 Erich Gamma CLA 2001-12-14 06:57:29 EST 
Created attachment 175 [details]
optimize it trace
Comment 5 Philipe Mulet CLA 2001-12-14 10:17:21 EST 
The claim is that no matter how many times we try, it remains slow. If the file 
is big (as it is), it should cost to populate the JavaModel once exactly, from 
there on it should be fast.

Seems the parameter name computation is causing grief.

Please investigate.
Comment 6 Philipe Mulet CLA 2001-12-18 07:13:47 EST 
Might also want to look at 7034 which has the same symptoms.
Comment 7 David Audel CLA 2002-01-07 11:01:00 EST 
receiver type file is read in jar file for each method of this type.

fixed.
Comment 8 Philipe Mulet CLA 2002-03-20 11:35:10 EST 
*** Bug 11272 has been marked as a duplicate of this bug. ***