Community
Participate
Working Groups
After I started using Mylyn, I ran some queries on the eclipse.org bugzilla, which resulted in over 3000 tasks in my .mylyn/offline directory. I have subsequently deleted the queries from the task list, and I have manually deleted the files from the offline directory (in an effort to increase performance). Mylyn has been running OK, but then I activated the "focus on workweek" mode in the task list, which made the Archive (all tasks) category appear which contains all of the 3000+ tasks from the previous queries. When I open the Archive category, Eclipse freezes and there is lots of disk activity (this seems to become better once the data is loaded in memory, but eclipse still freezes for a moment) I'll attach a tread dump & my tasklist.xml.zip file (I can't figure out anything from the thread dump except that all threads are waiting for some swt widgets to paint themselves). I'm not sure if this is the same issue as #194430.
Created attachment 74292 [details] Thread dump A thread dump of Eclipse freezing while opening Archived tasks
Created attachment 74293 [details] Task list data
Kim, is your .mylyn directory located on the local drive? The thread dump you have attached does not contain any Mylyn classes (it is usually a good idea to take several dumps with small interval to get a better picture). It is possible that it is as slow as the SWT Three widget with so many elements. bug 175318 or bug 152710 would address that by reducing number of element in given folder, please vote on those.
Yes, I moved my workspace & .mylin folder to a local drive. I took several thread dumps, all of which show more or less the same (some SWT work going on), so I attached only one. I'm not sure that this is a scaling issue with the tree widget. While investigating that possibility, I found out that the performance drop happens only when the category headers are in view. As soon as I scroll down far enough, performance increases to normal levels, and suddenly drops as soon as the category headers come into view (I can even have the task list as a fast view). Is Mylyn doing something that forces the tree widget to repaint/refresh itself, or is that normal SWT behavior to refresh the whole tree once a parent node comes into view?
I do see 1..2 seconds pause when expanding folder with few thousand elements and since that stack trace don't have any mylyn packages I would think that the problem lay down on the SWT side.
Do you think it would be sufficient to write a mock-up view with a simple TreeViewer that has several thousand items to prove/disprove the idea? Also, I found that SWT/JFace supports "virtual" tables and trees that get constructed incrementally (and also "lazy" virtual viewers, that also query the content provider on demand, and not up front). I'm not sure if sorting & filtering is supported by virtual treeviewers, but since 3.3 it is definitely supported for tables. http://www.eclipse.org/articles/Article-SWT-Virtual/Virtual-in-SWT.html http://wiki.eclipse.org/index.php/JFaceSnippets#Snippet029VirtualTableViewer
Tree is already virtual, however it is not free to create a sorted and filtered model with few thousand children. I see that archive node expands faster when I filter out completed tasks from the view menu. The only option I can think of is to move logic with regexp right into the abstract task instance, so it will be possible to cache it, instead of recreating groups on every comparison. This is the stack trace (very hard to catch): "main" prio=6 tid=0x00296000 nid=0xe9c runnable [0x0090e000..0x0090fe5c] java.lang.Thread.State: RUNNABLE at java.lang.String.length(String.java:652) at java.util.regex.Matcher.getTextLength(Matcher.java:1140) at java.util.regex.Matcher.reset(Matcher.java:291) at java.util.regex.Matcher.<init>(Matcher.java:211) at java.util.regex.Pattern.matcher(Pattern.java:888) at org.eclipse.mylyn.internal.tasks.ui.views.TaskKeyComparator.split(TaskKeyComparator.java:52) at org.eclipse.mylyn.internal.tasks.ui.views.TaskKeyComparator.compare(TaskKeyComparator.java:23) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListTableSorter.compareElements(TaskListTableSorter.java:139) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListTableSorter.compare(TaskListTableSorter.java:107) at org.eclipse.jface.viewers.ViewerComparator$1.compare(ViewerComparator.java:187) at java.util.Arrays.mergeSort(Arrays.java:1293) at java.util.Arrays.mergeSort(Arrays.java:1281) at java.util.Arrays.mergeSort(Arrays.java:1282) at java.util.Arrays.mergeSort(Arrays.java:1282) at java.util.Arrays.mergeSort(Arrays.java:1281) at java.util.Arrays.mergeSort(Arrays.java:1282) at java.util.Arrays.mergeSort(Arrays.java:1282) at java.util.Arrays.mergeSort(Arrays.java:1281) at java.util.Arrays.sort(Arrays.java:1210) at org.eclipse.jface.viewers.ViewerComparator.sort(ViewerComparator.java:185) at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:604) at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2497) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1826) at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:692) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1801) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1757) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1743) at org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:1433) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1368) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:378) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1330) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1431) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:503) at org.eclipse.ui.dialogs.FilteredTree$NotifyingTreeViewer.refresh(FilteredTree.java:818) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView$10$2.run(TaskListView.java:860) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) - locked <0x04239c80> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3659) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3296) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) ...
Another possibly related stack trace. I took this one when whole workbench was really really slow and it was staying like that for quite some time untill I scrolled Task List view. I am running dev build from last week (it doesn't seem like there was one this Friday) BTW, it would make sense to make TaskListView.refresh() method protected to avoid synthetic access$ method creation. "main" prio=6 tid=0x00296000 nid=0xe9c runnable [0x0090e000..0x0090fe5c] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.win32.OS.SendMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.SendMessage(OS.java:2900) at org.eclipse.swt.widgets.Tree.getColumnCount(Tree.java:2871) at org.eclipse.swt.widgets.TreeItem.setFont(TreeItem.java:1451) at org.eclipse.jface.viewers.TreeViewerRow.setFont(TreeViewerRow.java:118) at org.eclipse.jface.viewers.ViewerCell.setFont(ViewerCell.java:142) at org.eclipse.jface.viewers.TableColumnViewerLabelProvider.update(TableColumnViewerLabelProvider.java:92) at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:135) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:911) at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:97) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:857) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:46) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:193) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:988) at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:466) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:857) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:46) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:193) at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2026) at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2605) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1826) at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:692) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1801) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1757) at org.eclipse.jface.viewers.StructuredViewer$8.run(StructuredViewer.java:1460) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1368) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:378) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1330) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1458) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:514) at org.eclipse.ui.dialogs.FilteredTree$NotifyingTreeViewer.refresh(FilteredTree.java:823) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView.refresh(TaskListView.java:1548) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView.access$4(TaskListView.java:1538) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView$5$1.run(TaskListView.java:484) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) - locked <0x13ea3578> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3659) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3296) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) ...
Eugene: unless we slipped up somewhere the TaskListView's tree should not be SWT.VIRTUAL because I saw some problematic interaction between virtual trees and filtered trees, which generally need quick access to all the tree's elements. Btw, which TaskListView.refresh() method are you suggesting we make protected? If that doesn't create accessibility problems I don't see a problem with doing it. Good that you found the regexp as the potential source of the slowness. I want to avoid caching anything on RepositoryTask for modularity reasons, but we could create a separate structure for caching if this is a promising way of addressing the problem. However, I still wonder why I've never seen such slowness. Kim: there should be no problem handling a list of thousands of elements, mine has almost 6K just in the archive. How long is the lock-up? If you want to delete unwanted tasks just unfilter the archive via the view menu and delete them from there if your queries are gone, or re-create the queries to delete the tasks from within the queries. Regarding the tree widget, I have profiled it with 10s of thousands of nodes and have not seen a problem.
(In reply to comment #9) > Btw, which TaskListView.refresh() method are you suggesting we make protected? > If that doesn't create accessibility problems I don't see a problem with doing it. There is only one refresh() method there and it is private. Because it is private javac creates public synthetic method that you can see in the above stack trace as TaskListView$10$2.run(TaskListView.java:860). There is actually a compiler warning for that which is set to be ignored in all modules here: "Access to a non-accessible member of an enclosing type". When enabled, the compiler will issue an error or a warning whenever it emulates access to a non-accessible member of an enclosing type. Such accesses can have performance implications. I guess performance penalty is quite low, but still it is not nice. > Good that you found the regexp as the potential source of the slowness. I am not certain about that without profiling, but it is obvious that this code is called many times. > I want to avoid caching anything on RepositoryTask for modularity reasons, but we > could create a separate structure for caching if this is a promising way of > addressing the problem. However, I still wonder why I've never seen such > slowness. I don't think separate structure would be a good idea and don't really see why AbstractTask can't implement Comparable that comparator would delegate to. This trick is used in JDK quite widely, i.e. hash code calculation in the String class. BTW, it seems like when task list is sorted by priority Archive category expands slightly faster.
(In reply to comment #9) > Kim: there should be no problem handling a list of thousands of elements, mine > has almost 6K just in the archive. How long is the lock-up? It feels like 2 seconds every time I display the task list or scroll while having the category header in view (even when the category list is already expanded). I'll try to do a screencast so you can judge for yourself. > If you want to > delete unwanted tasks just unfilter the archive via the view menu and delete > them from there if your queries are gone, or re-create the queries to delete the > tasks from within the queries. Actually, there seems to be another bug with deleting the tasks from the archive (I haven't had the time to check if it isn't already reported so I don't report a duplicate), because it seems like the list gets refreshed for each and every deleted task. With 3k tasks and a delay of 2 seconds per refresh... well I had to shut down eclipse.
Created attachment 74564 [details] Screencast of task list behavior As promised, here is a screencast (I think you'll need flash 6 to play it). It starts of with a normal task list, showing the archive category, bit of scrolling, then switching on workweek mode, opening the archive and scrolling. I didn't show hiding the view, but the performance problems are the same. To my surprise, the problematic behavior really shows up only in the "focus on workweek" mode. I actually mentioned this in the original report, but I didn't realize this was specific to the workweek mode (I didn't even know that you could show the archive otherwise). Performace in "normal" mode is quite acceptable (after the tree is initially expanded). Also note that rendering artifacts (like stuck tooltips) are real (not a result of the screencast software).
Wow, thanks for the video, that's very helpful. I described the problem and work-around in my reply on the newsgroup. What's happening with the Focused mode is that it shows all unread tasks, and you have a number that's so large that the FilteredTree mechanism is not scaling. Since you almost certainly don't want all of these tasks you will have to delete them all. Your options for doing that are now listed at: http://wiki.eclipse.org/index.php/Mylyn_FAQ#The_Archive_category_contains_many_irrelevant_tasks.2C_how_do_I_clean_it_up.3F Alternately you could edit workspace/.metadata/.mylyn/tasklist.xml.zip if the deletion/refresh cycle is taking way too long and if you don't want to throw away your current Task List, but my recommendation is to let it run. The artifacts in the tooltips are likely to be the result of the fact that Windows is getting too many redraw requests. Let me know how this works out. Also, it would be helpful to know how you got this many tasks into your Task List. We used to have more safeguards in place for preventing large queries to overload the Task List in this way, but they were causing confusion. Since I'll be away for the next couple of weeks I'm assigning to Rob.
Here is another potential performance hog. The TaskPriorityFilter should read its property once and register itself as property listener instead of read that boolean flag on every call. java.lang.Thread.State: RUNNABLE at org.eclipse.core.internal.preferences.EclipsePreferences.node(EclipsePreferences.java:662) at org.eclipse.core.internal.preferences.RootPreferences.getNode(RootPreferences.java:106) at org.eclipse.core.internal.preferences.RootPreferences.node(RootPreferences.java:85) at org.eclipse.core.internal.preferences.AbstractScope.getNode(AbstractScope.java:38) at org.eclipse.core.runtime.preferences.InstanceScope.getNode(InstanceScope.java:71) at org.eclipse.ui.preferences.ScopedPreferenceStore.getStorePreferences(ScopedPreferenceStore.java:238) at org.eclipse.ui.preferences.ScopedPreferenceStore.getPreferenceNodes(ScopedPreferenceStore.java:280) at org.eclipse.ui.preferences.ScopedPreferenceStore.internalGet(ScopedPreferenceStore.java:471) at org.eclipse.ui.preferences.ScopedPreferenceStore.getBoolean(ScopedPreferenceStore.java:383) at org.eclipse.mylyn.internal.tasks.ui.TaskPriorityFilter.select(TaskPriorityFilter.java:36) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListContentProvider.filter(TaskListContentProvider.java:279) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListContentProvider.getFilteredChildrenFor(TaskListContentProvider.java:246) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListContentProvider.getChildren(TaskListContentProvider.java:87) at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:1317) at org.eclipse.jface.viewers.TreeViewer.getRawChildren(TreeViewer.java:366) at org.eclipse.jface.viewers.AbstractTreeViewer.getFilteredChildren(AbstractTreeViewer.java:615) at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:581) at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2497) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1826) at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:692) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1801) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1757) at org.eclipse.jface.viewers.StructuredViewer$8.run(StructuredViewer.java:1460) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1368) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:378) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1330) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1458) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:514) at org.eclipse.ui.dialogs.FilteredTree$NotifyingTreeViewer.refresh(FilteredTree.java:823) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView.refresh(TaskListView.java:1548) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView.access$4(TaskListView.java:1538) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView$5$1.run(TaskListView.java:484) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) - locked <0x115dff88> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3659) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3296) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
Great catch. Please file a new bug for that since we should do it for 2.1.
(In reply to comment #13) > Wow, thanks for the video, that's very helpful. I described the problem and > work-around in my reply on the newsgroup. What's happening with the Focused > mode is that it shows all unread tasks, and you have a number that's so large > that the FilteredTree mechanism is not scaling. Since you almost certainly > don't want all of these tasks you will have to delete them all. The huge number mentioned in the newsgroup was a typo, the actual number is a little over 3000 tasks (I tried to get the task number tooltip in the screencast, but I probably forgot to do a mouse-over in the final version). > Alternately you could edit workspace/.metadata/.mylyn/tasklist.xml.zip if the > deletion/refresh cycle is taking way too long and if you don't want to throw > away your current Task List, but my recommendation is to let it run. Actually, deletion is quick (the tasklist.xml.zip file was correctly updated a few moments after hitting the "del" key), its only the visual refresh that is problematic (restarting eclipse quickly brought up a task list with all tasks that I wanted to be deleted deleted). I'll go file a separate bug.
Steffen: this is related to the performance work that you have been driving. Major improvements may depend on bug 210801. However, for Mylyn 2.2. we should make sure that we never get into the scenario where we see a lock, and this is still happening. The stack traces I'm seeing most frequently are: at java.lang.String.equals(String.java:1018) at org.eclipse.mylyn.tasks.core.AbstractTaskContainer.containsHelper(AbstractTaskContainer.java:108) at org.eclipse.mylyn.tasks.core.AbstractTaskContainer.contains(AbstractTaskContainer.java:102) at org.eclipse.mylyn.tasks.core.TaskList.getQueriesForHandle(TaskList.java:554) at org.eclipse.mylyn.internal.tasks.ui.TaskWorkingSetFilter.select(TaskWorkingSetFilter.java:58) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListContentProvider.filter(TaskListContentProvider.java:234) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListContentProvider.getFilteredRootChildren(TaskListContentProvider.java:217) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListContentProvider.getFilteredChildrenFor(TaskListContentProvider.java:176) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListContentProvider.getChildren(TaskListContentProvider.java:83) at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:1331) at org.eclipse.jface.viewers.TreeViewer.getRawChildren(TreeViewer.java:378) at org.eclipse.jface.viewers.AbstractTreeViewer.getFilteredChildren(AbstractTreeViewer.java:615) at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:581) at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:778) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:755) at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:627) at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpandToLevel(AbstractTreeViewer.java:1686) at org.eclipse.jface.viewers.AbstractTreeViewer.expandToLevel(AbstractTreeViewer.java:1033) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView$7.updateExpansionState(TaskListView.java:744) at org.eclipse.mylyn.internal.tasks.ui.views.DelayedRefreshJob.refresh(DelayedRefreshJob.java:102) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView$7.refresh(TaskListView.java:738) at org.eclipse.mylyn.internal.tasks.ui.views.DelayedRefreshJob.runInUIThread(DelayedRefreshJob.java:85) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:94)
These performance issues pointed out on this bug report have been addressed by improving the task list refresh policy (bug 194430) and optimizing the lookup for incoming notifications and filtering (bug 207659, bug 205357).
