Summary: | [index] Hang waiting for Java Type Dialog | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Billy Biggs <billy.biggs> |
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | douglas.pollock, john.arthorne, Mike_Wilson |
Version: | 3.1 | Keywords: | performance |
Target Milestone: | 3.1 M7 | ||
Hardware: | PC | ||
OS: | Linux-GTK | ||
Whiteboard: |
Description
Billy Biggs
2004-11-25 13:50:06 EST
I've seen this hang as well. GTK+ 2.2.1. Are you sure about the Eclipse version? And have you talked to Silenio about this? I'm sure of the GTK+ version. Note that the UI was not blocked and was able to respond to expose and resize events, so I do not think this is an SWT problem. Do you remember having cancelled the OpenType dialog opening prior to hanging ? No, I don't recall having done that. I cannot reproduce using GTK+2.2.1 and last integration build I200411240800. Billy, have you seen this hang recently ? If you have, do you have anything related to indexing in your .log file ? I am able to reproduce this one. Make sure you start up Eclipse with a *closed* Java project. After startup, open the project and then Open Type. The progress dialog will be there forever. The Cancel button is active though. Before the Open Type works again, I have to rebuild the project and restart Eclipse. Ringo Forgot to mention: Eclipse 3.1M3 on Windows 2000 with JDK 1.4.2_05. I am still running M3 since post-M3 builds annoy me due to Bug 73969. Ringo Has the JDT Core team managed to reproduce the problem using the steps given by Ringo? Note: If it is taking a long time to open, then it's a performance problem. If it *hangs* (i.e. never opens) then it's a bug whose priority should probably be raised. I doubt we can reproduce this PR using HEAD since the AllTypesCache was removed last week. Time spent in scenario described by Ringo is to index files of the reopened project(s). Here are times noticed on an Eclipse 3.1 full source workspace (86 projects): 1) Close all projects: ~45s 2) Open all projects: ~7 s 3) Index all files (~10600): ~30s So, time to index all files sounds definitely reasonable... Moreover, this scenario should happen seldom as user does not close/open often big projects and even if it happens, indexing progress is shown to user in dialog. So, he cannot longer feel that eclipse is currently hanging. Due to all these reasons, I close this bug as FIXED. Re: "Close all projects: ~45s" Just out of curiosity, why does it take 45 seconds to *close* all the projects. If the projects are all closed, then there should be nothing to index. It seems like it should be almost instant. Mike, I didn't say that index take 45s while closing project. AFAIK, there's no indexing during this operation. I put this time just to make indexing time relative to other operations on same number of projects... Apologies Fred. I misread. Adding JA to CC list to answer the question: Why does closing all projects take 45s? I have entered Bug 94436 to investigate performance of closing projects. This does have to do significant work, since it saves the project subtree to disk. Other PRE_CLOSE resource change listeners might also be adding some time. Verified for 3.1 M7 using build I20050509-2010 + jdt.core HEAD. |