Summary: | Startup takes too long with java editor open | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Kevin Haaland <Kevin_Haaland> | ||||
Component: | Core | Assignee: | David Audel <david_audel> | ||||
Status: | RESOLVED WONTFIX | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P2 | CC: | jed.anderson, peter_burka | ||||
Version: | 2.0 | Keywords: | performance | ||||
Target Milestone: | 2.1 M5 | ||||||
Hardware: | PC | ||||||
OS: | Windows 2000 | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Kevin Haaland
2002-05-29 16:08:37 EDT
MonoReconciler running is OK. It does so in a separate thread and should not prevent the editor from coming up. Profiling information would help to see whether the two threads *UI, MomoReconciler) block each other. is there any way this workspace could be ftp-ed to us so that we can analyze the trace? Yes, but it's VERY big. (~1GB including required support files). Kevin and I are going to try to profile it here, first. Created attachment 1128 [details]
Here is the stack dump
Got it. See attachment for details. The time is spent creating the outline view contents. Using the same setup as before but this time deleting the outline view the time to open the editor added the annotation to the wrong bug... ==== I wonder whether the override indicator is the problem. Can you run the scenario again but with the override indicator turned off: Preferences>Java>Appearance: Show Override Indicator in outline and hierarchy Changing the Show Override Indicator setting had no effect on the startup times. I also tried changing the scenario so that the Outline was open on Object at startup, since this is a much simpler class. This actually made startup even slower (>250sec). This might be asking for a lot, but what would really help us the most is an Optimize perf trace of the start-up time. Can you produce this and export as html? Otherwise we have to do the workspace ftp-transfer. Just as a data point: our current start-up time in a self hosting workspace with one Java file is 40s (-6s from previous builds). The trace shows that the UI thread is waiting on the JavaModelManager lock that is held by a reconciler thread. Closing the outline view makes the problem go away since then the UI thread will not request for the element info that makes it wait for the lock. The problem seems to be that the JavaModelManager lock is kept for an extended period of time. Philippe do you see a way to shorten the time that this lock is held. Moving to JDT Core for investigation. Indeed the lock on the project element creation comprises the namelookup initialization (need to find all package fragment roots + all package fragments). Changing the concurrency characteristics at this stage is likely asking for trouble elsewhere... need to be really careful. David - pls gather some profiling stats using reasonable workspace (tried on a large on, and had to kill it after an hour waiting for it to show up). The stack dump only exposes the fact that 2 identical namelookups are being created concurrently. This is causing some competion on locks. We changed the implementation so as to avoid 2 concurrent creations of the same namelookup, but the timing won't look much different, in so far as one will wait idle while the namelookup is ready to use. So the characteristics will be pretty much the same. I can not reproduce the long startup. If the last build did not improve the startup time, could you ftp-ed to us your very very huge workspace. Closing as not reproduceable. Also various changes occurred to reduce our startup time (no longer checking index consistency). |