Community
Participate
Working Groups
Open Resource dialog often freezes for up to 5 seconds with "Searching 23%" displayed in the right corner, usually after typing one or two characters. Both typing and mouse operations are blocked in that state. This behavior almost nullifies the advantage of the fast search the dialog provides. All ongoing activity should be immediately canceled when a user presses a key or clicks on something.
I've done a quick test in 3.3 (but not 3.3.1) and am not seeing this behaviour. The message you describe sounds like it might be the indexer running, but that should only be possible immediately after loading resources or a full build and doesn't match your "often" comment. I tried with 20 projects loaded (most of org.eclipse.ui to org.eclipse.ui.workbench.texteditor). Can you please describe approx the # of project/resources you have loaded? Also, let us know if there's anything particular about your setup or usage (e.g. many linked resources).
The workspace contains a single project with 15 linked folders. There are just a few files included directly, the rest 30K files are under the linked folders. The files are on NFS. The duration of the freeze varies from time to time, but the long freezes are not uncommon.
Although this isn't a deadlock, can you attach a stack dump from the time it is frozen as described here: http://wiki.eclipse.org/index.php/How_to_report_a_deadlock That will tell us exactly what's going on at the time it is frozen.
Created attachment 80094 [details] Few stack snapshots The stacks are obtained with 3.4M2. Please let me know if you need me to do more experiments.
Thanks for the stack traces Sergey. The freezing is caused by a Perforce plugin: at java.io.FileInputStream.read(FileInputStream.java:194) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) - locked <0x9d4df3e8> (a java.io.BufferedInputStream) at com.perforce.p4api.PythonMarshall.readObject(PythonMarshall.java:144) at com.perforce.p4api.PythonMarshall.readDictionaries(PythonMarshall.java:45) at com.perforce.p4api.PerforceConnection.exec(PerforceConnection.java:404) at com.perforce.p4api.PerforceConnection.exec(PerforceConnection.java:329) at com.perforce.p4api.PerforceFileAccess.statFiles(PerforceFileAccess.java:288) at com.perforce.team.ui.PerforceAccess.statFiles(PerforceAccess.java:317) at com.perforce.team.ui.decorator.Folder.getFiles(Folder.java:112) at com.perforce.team.ui.decorator.PerforceDecorator.decorateText(PerforceDecorator.java:349) That decorator really shouldn't be doing long-running work such as reading files from disk. I suggest reporting this to the provider of the Perforce plugin. However, it's possible the dialog could handle this by performing decoration in a background thread. Moving to UI for comment.
(In reply to comment #5) Thanks for the quick response. Indeed, disabling decorations eliminates the problem.
Thanks for the help John. Its a good point that perhaps we shouldn't be doing this in the foreground. In theory decorators can be quite slow (e.g. get version info from a server). I've renamed the bug title to denote the real platform UI specific part of the bug. Routing to Tod for comment.
I'm not clear whether the suggestion is to do something specific in the open resource dialog or handle this at the decorator level. Routing to the [Decorators] component for comment.
(In reply to comment #8) > I'm not clear whether the suggestion is to do something specific in the open > resource dialog or handle this at the decorator level. Routing to the > [Decorators] component for comment. It was that we might be able to do more decorator work in a background thread. But the work itself is all in the extender, and as I think about it, that'd mean changing the contract with the callers on which thread we're issuing work on, so I don't see this change happening. I'm closing this bug since the original problem (bad perforce decorator) is not eclipse, and I don't see anything else realistically that we could do to improve things. Please reopen, or open a new bug, if ideas.
(In reply to comment #9) > (In reply to comment #8) > > I'm not clear whether the suggestion is to do something specific in the open > > resource dialog or handle this at the decorator level. Routing to the > > [Decorators] component for comment. > > It was that we might be able to do more decorator work in a background thread. > But the work itself is all in the extender, and as I think about it, that'd > mean changing the contract with the callers on which thread we're issuing work > on, so I don't see this change happening. Could you please elaborate on the contract you referred to and the place where it's documented. Eclipse has a long history of moving work from UI to background threads. How the decorators case would be different from previous ones? > I'm closing this bug since the original problem (bad perforce decorator) is not > eclipse, and I don't see anything else realistically that we could do to > improve things. Please reopen, or open a new bug, if ideas. I strongly disagree with this assessment. The problem is not that the decorator is bad. Some decorators should be assumed to be slow since they do complex work. The problem is that the dialog executes decorators synchronously in spite of the fact that the decorations are not essential for the primary function of the dialog.
Oleg is now responsible for watching the [Decorators] category.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
