Bug 61386 - [performance] Apply working sets to the JRE
Summary: [performance] Apply working sets to the JRE
Status: RESOLVED DUPLICATE of bug 119419
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-07 10:21 EDT by Chris Laffra CLA
Modified: 2007-06-22 04:58 EDT (History)
2 users (show)

See Also:

Attachments
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 Chris Laffra CLA 2004-05-07 10:21:01 EDT 
With the move to JDK 1.4 I (and others) observed considerable increase in 
startup time for Eclipse 3.0 -- especially when using JDT.
Memory consumption and disk I/O also goes up. Most of this can be explained
by JRE 1.4 being much larger than 1.3. JDT has to read "core.jar" to index the 
classes. As a result, the cache grows bigger. Searching takes more time, etc.  

I propose we use a JDT option to control package consumption from the JRE.
For my project, I do not need all those classes. Don't show any javax classes,
and hide the Swing classes, as I am now working on an SWT UI.
This will increase the ratio of right hits when I type Ctrl-Shift-T 'Button'
and inadvertently sometimes end up with the wrong Button.

Performance is the issue here. JDT should filter core.jar
Comment 1 Philipe Mulet CLA 2004-05-10 05:17:24 EDT 
This notion should be directly bundled into VM support.
The CP container could only expose a subset of the actual set of JARs (for 
which some are only needed at runtime).
Comment 2 Darin Wright CLA 2004-05-12 09:44:00 EDT 
Nothing planned for 3.0
Comment 3 Darin Wright CLA 2007-06-21 13:09:52 EDT 
Users can already customize the jars associated with a JRE (you can remove/add jars as you see fit). However, this request is to limit the visibility within a jar. There are already access rules to limit visibilty - but I believe the entire jar is still read. Code assist is limited to visible classes, but "Open Type" still shows all types, filtered or not.
Comment 4 Darin Wright CLA 2007-06-21 13:10:17 EDT 
Moving to JUI for comment, I don't think there's anything left for debug to do here.
Comment 5 Martin Aeschlimann CLA 2007-06-22 03:41:05 EDT 
I don't think access rules can really help improving the performance. 
What we would need are exclusion rules on JARs that would hide certain types or packages completely from the Java model (bug 119419)

For the open type dialog, we offer type filters (Java > Appearance). As access rules are project specific, they don't apply to the workspace global open type dialog. I also believe users want to open invisible (internal) types.

Do you want to mark this bug as a dup of 119419?
Comment 6 Jerome Lanneluc CLA 2007-06-22 04:36:55 EDT 
(In reply to comment #5)
> Do you want to mark this bug as a dup of 119419?
I'm not sure who this question is addressed to, but yes it would make sense to mark it as a dup of bug 119419.
Comment 7 Martin Aeschlimann CLA 2007-06-22 04:58:15 EDT 

*** This bug has been marked as a duplicate of bug 119419 ***