Community
Participate
Working Groups
I noticed this when browsing trough Eclipse source code (no code in my workspace, just pde source attachments to plugin jars) and for some reason ctrl-click on method name in Java editor triger task list refresh, which then blocks workbench UI for more then 30 seconds
Created attachment 73843 [details] thereaddump Here is the thread dump captured while workbench UI is blocked. I captured it few times, so you can look for "main" thereads in the attached log. I forgot to mention that there was no active task.
Note that org.eclipse.ui.dialogs.PatternFilter.isLeafMatch(..) is generally slow and there is no good way to unblock the UI while it is happening. However, Shawn and I recently discovered an alternate caching strategy that can help it, so I will explore whether we can use that for the Task List.
(In reply to comment #2) Do you mind to elaborate?
It recursively accesses parents/children in order to determine whether there are leaf matches. I didn't make a close analysis but complexity is unlikely to be better than x*O(n log n), where x is the time to access the element. X seems to be dominated by time spent in the content provider, which for the Task List should be fast, but is still likely to benefit from caching (see caching strategy on PatternFilter, we experimented some with a more efficient strategy).
As far as I know our remaining limitations of blocking the UI are those that we get from FilteredTree, and we currently have no plans of addressing those.
Resolving as per comment 5. Further optimizations to refreshes will be tracked on bug 208089.
