Bug 6866

Summary:

Code-Assist (ctrl+space) to slow with jre-src

Product:

[Eclipse Project] JDT

Reporter:

Martin Möbius <m.moebius>

Component:

Core

Assignee:

David Audel <david_audel>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

martinae, vladgri

Version:

2.0

Target Milestone:

2.0 M2

Hardware:

OS:

Windows NT

Whiteboard:

Attachments:

Description	Flags
optimize it trace	none

Description Martin Möbius

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

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

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

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

2001-12-14 06:57:29 EST

Created attachment 175 [details]
optimize it trace

Comment 5 Philipe Mulet

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

2001-12-18 07:13:47 EST

Might also want to look at 7034 which has the same symptoms.

Comment 7 David Audel

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

2002-03-20 11:35:10 EST

*** Bug 11272 has been marked as a duplicate of this bug. ***