Bug 15233 - Severe startup problem caused by having "show problems before compiling" option turned on
Summary: Severe startup problem caused by having "show problems before compiling" opti...
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 1.0   Edit
Hardware: PC Windows 2000
: P2 critical (vote)
Target Milestone: 2.0 M6   Edit
Assignee: Kai-Uwe Maetzel CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2002-05-03 16:01 EDT by Kevin Haaland CLA
Modified: 2002-05-09 07:27 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Haaland CLA 2002-05-03 16:01:27 EDT
Peter has a repeatable scenario where the time required to startup eclipse goes 
from 30 seconds to 4 minutes based on the setting of this editor option. 

In his particular case the file is relatively small but it does referece 118 
external jars. Sending you the workspace is possible (but will be difficult as 
it's aparently is 1 gig in size)

Is the code that runs during the startup case different? If instead of leaving 
the file open you close it, the editor opens in a "reasonable" time.

It also looks like there is a ton of work going on, when we ran this case in 
OptimizeIt we noticed close to 18000 class file objects had been created.
Comment 1 Erich Gamma CLA 2002-05-05 15:21:04 EDT
Just to be sure...
1) Peter is using the latest build
2) The problem shows up when a single Java file is persisted across a session
(i.e., the potential workbench optimization to only open the visible editor on 
startup would not help).

Opening an editor with "show problems" requires significant type analysis and 
this can explain why that many class files got analyzed (carboned Philippe for 
more details).

The initial reconcile is done in the UI thread to initialize the temporary 
problems. Afterwards the reconciling is done in a reconciler thread on document 
changes by the user. Is it an option to do the problem initialization in the 
reconciler thread as well? 
Comment 2 Peter Burka CLA 2002-05-05 20:31:46 EDT
I'm using the M5 stable build.

I only need to have one editor open (persisted) to demonstrate the problem.

I can work around the problem by:
 a) closing all editors before exiting
 b) disabling "show problems before compiling" before exiting

I suspect that the problem may be exacerbated by the number of external JAR 
files referenced by each project. Many of my projects include 100+ external JAR 
files. I think that many of these are duplicates (i.e. the same external JAR is 
included in more than one project). Is it possible that each JAR file is being 
processed multiple times, once per project it's included in?
Comment 3 Philipe Mulet CLA 2002-05-06 04:42:42 EDT
Only JARs visible to this one file should be considered. Could you post the 
workspace somewhere (ftp) ?
Comment 4 Peter Burka CLA 2002-05-06 10:22:24 EDT
The workspace relies on a second Eclipse (WSAD) install. That's where all of 
the external JARS are. The total size of the two would exceed 1.5GB. I'd like 
to avoid zipping and FTPing that, if I could.

I've made a few more observations:

- If I have a .java file open from a project which is independent of the other 
projects in my workspace, startup is fast.

- My project has 111 JARs on its Java class path, and 9 projects. None of the 
projects export anything other than their src directory.
Comment 5 Kai-Uwe Maetzel CLA 2002-05-09 07:27:18 EDT
Any problem detection is now performed in the reconciler thread.
Build 20020508.