Bug 11487 - Superclass browse button on New Java Class wizard is slow [code manipulation]
Summary: Superclass browse button on New Java Class wizard is slow [code manipulation]
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P4 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2002-03-15 13:30 EST by Matt Lavin CLA
Modified: 2009-08-30 02:41 EDT (History)
0 users

See Also:


Attachments
new type wizard - Browse supertype button (7.56 KB, text/plain)
2002-12-11 10:31 EST, Adam Kiezun CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Lavin CLA 2002-03-15 13:30:56 EST
When the user clicks on the "Browse..." button next to the Superclass text 
field in the New Java Class wizard they have to watch the progress bar go 
across the bottom of the wizard.  I assume that it is building a list of 
classes that are visible from the current SourceFolder.  It would be really 
nice if that list was built up in the background while the user is typing the 
name of the new class.  If the user never clicks the browse button then the 
list can be thrown away, and if the user clicks the browse button before the 
list has completed then the progress bar can pickup where it currently is.  I 
would imagine that most of the time, the list can be loaded before the user 
clicks on the browse button.
Comment 1 Erich Gamma CLA 2002-03-18 13:38:44 EST
should be revisited during the performance work
Comment 2 Adam Kiezun CLA 2002-12-11 10:31:52 EST
Created attachment 2751 [details]
new type wizard - Browse supertype button

here's the trace
Comment 3 Adam Kiezun CLA 2002-12-11 10:36:37 EST
asking Martin for comment and further action
btw, there's no busy cursor either
Comment 4 Martin Aeschlimann CLA 2002-12-11 12:05:25 EST
This dialog is using the same dialog that the all types dialog uses.
There it's the same: classes are searched first, and then the dialog is opened.

Busy cursor is there.

Moving back to jdt.ui as this is a TypeSelectionDialog issue
Comment 5 Adam Kiezun CLA 2002-12-11 12:17:45 EST
there's no busy cursor - try it on Action
(select Action and try creating a subclass of it)

Comment 6 Dirk Baeumer CLA 2003-01-29 12:05:29 EST
I20030128 displays a busy cursor in this case. Regarding performance: the 
performace is comparable to the Open Type performance. This means that the 
first time the browse button is pressed, the type cache may be populated. If 
so, you see appropriate progress feedback in the progress monitor.

Most time is spent in JavaSearchScope. Moving to JDT Core for comments.
Comment 7 Philipe Mulet CLA 2003-01-29 17:06:19 EST
Matt's original comment is still valid. Asking for some background computation 
of the list would indeed improve this situation. 

Computing the list of all types in the workbench has a cost, I doubt we could 
reduce it that much. 

Comment 8 Dirk Baeumer CLA 2003-01-30 04:54:31 EST
As I said the list is precomputed in 90% of the cases since it is shared with 
the open type dialog. It must only be recomputed if new types where added or 
existing types deleted.

There are no plans to improve this for 2.1 by doing a computation of the list 
in the background.
Comment 9 Eclipse Webmaster CLA 2009-08-30 02:41:05 EDT
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.