Community
Participate
Working Groups
It seems task editor performance does not scale well with the amount of comments. My machine is a: Core 2 duo, 2GB, Windows Vista. If you try to open a bug with ~100 comments, like bug#8009, and compare with another one with < 5 comments, like this one, you can note that: - The first one takes more time to open the editor, ~3 seconds on my machine, the second one ~1 second. - Expand the "Comments" section takes ~0,5 second, while the second one ~0,1 second. - Expand a single comment takes ~0,5 second, while the second one ~0,1 second. The comment expansion particularly bugs me, because while the ~0,1s in a "normal" bug is acceptable, it is sufficient to make the mouse cursor turn into a busy circle for a very quick moment. In the "big bug" scenario, it sounds strange because it looks like it is doing some heavy computation, but it is only repositioning the other controls. I don't know if there is something we could do at Mylyn's side because it looks like the only thing we could optimize here is control creation and layout optimization. I took a look at the forms API, and it appears the only way to handle the expansion correctly (and is the way actually used) is to invoke IManagedForm.reflow(true), but in the big task editor this means to invalidate and layout all the form == at least 100 * (expandable composites + icons + textviewer + hyperlinks, that composes a unique comment). I don't remember any application that uses so many controls in a unique UI, and perhaps there should be some optimization in SWT/Forms side.
Shawn: could you please put your latest Sleak profiling results here? Beyond finding any opportunities to share fonts or colors across comments, the underlying problem here is the fact that we instantiate multiple SourceViewers.
From what I found, there is 1 color created per comment: 2 comments: 41 colors, 1 font, 12 images 69 comments: 108 colors, 1 font, 12 images If both of these are open at the same time, the base colors (39 or so) are shared. The main problem seems to be that there is a color per comment created.
Shawn pointed out to me that the JFace DefaultHyperlinkPresenter class was instantiating a color on us because we were passing it an RGB, so changed that to pass it a color constant instead. The number of colors should no longer grow with the number of comments. Shawn: please verify.
Created attachment 81000 [details] mylyn/context/zip
*** Bug 208915 has been marked as a duplicate of this bug. ***
I've been suffering from similar performance problems with large bugs, but it's the redraw during scrolling that's been bugging me (on Windows XP), rather than any layout time. When viewing a task with a long list of comments, with all comments expanded, the time taken to perform any redraw is a significant fraction of a second on my Pentium-M class laptop. When paging up and down, this isn't too painful in itself - you just click on the scroll well, then wait for the content to appear. But when scrolling up and down by dragging the scroll bar or using a scroll wheel, with immediate scrolling enabled, you're left with a big smear of text across the window unless you pause scrolling long enough for the redraw to happen; the event prioritisation is such that it never gets round to redrawing any new areas, only doing rectangle copies until you stop scrolling, giving a window full of rendering artifacts. This isn't pretty. The slow redraw can also be seen when dragging a window in front of the task editor, although in that case the drag is frozen until the redraw catches up, so you don't see visual artifacts.
Kevin, I see this too, and I guess this is not necessarily because of the large comment list, but it just exposes a redrawing problem. This is very easy to reproduce: just open any task editor with a sufficient large list of comments to have a vertical scroll bar, and scroll with the mouse wheel. You will see a "dirty repaint" effect on editor while scrolling.
Not enough time for feedback on major UI changes of this sort for 2.2, so unfortunately pushing to 2.3.
I am concerned that it is too easy to get into an excessive amount of use of handles with task editors, especially on Windows Vista (bug 211124). What I have done to address this for now is put in a hard limit on task editor reuse, where the least-frequently used editor will be auto closed when the max is hit. Dirty editors or those with incomings and outgoings will not be closed. The max is currently hard-wired to 12 and I would like to avoid making it a preference. It is not likely for anyone to hit max handles until they've got a few times that in number of editors open, so we can consider raising it. However, task editor bloat has usability problems of its own, so it could be good to keep the max under 20.
Created attachment 85504 [details] mylyn/context/zip
Sounds good to me Mik. And in 2.3 we can reduce this number of handles per editor by reducing the number of viewers.
(In reply to comment #9) > I am concerned that it is too easy to get into an excessive amount of use of > handles with task editors, especially on Windows Vista (bug 211124). What I > have done to address this for now is put in a hard limit on task editor reuse, > where the least-frequently used editor will be auto closed when the max is hit. > Dirty editors or those with incomings and outgoings will not be closed. The max > is currently hard-wired to 12 and I would like to avoid making it a preference. I am concerned about this, as with other hidden policies. Even if it is documented somewhere, it is still not very obvious to the end user when editors will be closed. For example I can envision scenario when user opens editor for the currently active task and then goes into the Task List or the Search view to browse trough some other tasks (it can go way beyond 12). In result interesting task editors will be unexpectedly closed. So, all in all property similar to Platform's "close editors automatically" will give more visibility to this feature.
We have an editor with similar design to the Mylyn issue editor (multiple SourceViewers in ExpandableComposites) that exhibits similar performance problems. We have come up with a solution that works well for our editor, drastically reducing the initialization time. In case it might be of use for the Mylyn editor, I'm posting a summary of what we did here. Our solution relies reducing the number of SourceViewers for a given editor instance. SourceViewers are only instantiated if they're visible. If an ExpandableComposite is expanded, the SourceViewer is added to it in an IExpansionListener, and if it is collapsed, the SourceViewer is disposed. In our editor this approach greatly reduces the number of SourceViewers that exist at any given point in time (granted if someone expands all composites, this approach would have no benefit -- however we've found that typical use rarely involves expanding all composites) I hope that helps. David
David, this is exactly what we plan to do so it is great to hear this has been done with some success! Were any extra tricks required to reduce the amount of form re-layout required after expanding/collapsing the expandable composites?
I didn't mention that we also use a Composite container for each SourceViewer, where the Composite has a custom LayoutManager and no other children. The LayoutManager might have an effect on performance, however that's not why we introduced it. We find that the line wrapping behaviour of the StyledText is better using our LayoutManager. I haven't yet used a profiler to analyze the new setup, so it's hard to say exactly what is working. Our initialization time though has gone from about 2s to < 0.2s. I'm off work now until the 2nd, and probably won't get to it until the 16th of January -- so I'm afraid that I can't give you much more information with any degree of certainty.
Created attachment 85698 [details] the layout manager that we use attached the layout manager that we're using. Notice that is uses a width hint but no height hint, which will cause the StyledText to compute a size that shows all of the text without a scrollbar.
Thanks David!
That is great to hear David! I'll implement performance tests to collect some data on the improvements once the new code is merged.
Awesome, thanks for the info David. In the new year we'll see a much faster editor!
Here are my results of a quick profiling of the improved task editor: On open : - The editor spends a bunch of time doing reflows. It looks like the editor is fully "reflown" when each section is created causing it to burn more time the more widgets are added. Is it possible to delay reflowing until all widgets are created? On expand of (all) comments: - The parser of the StyledText widgets consumes a lot of time parsing the comments. The parsing rules might need a refactoring to make them more efficient. - The hyperlink detector triggers SWT exceptions that are ignored but cause 30% of the overhead. That might be a Linux only problem (looks similar to bug 203991).
Created attachment 86644 [details] don't reflow sections when opening editor This patch supresses reflows while constructing sections. According to the profiler editor opening went down from 6 seconds to 600 ms. Rob, it would be great if you could the patch to your bootstrap workspace and let me know if you can confirm that on Windows. Please note that the patch breaks the bold font style of section headers.
With this patch, creation of the editor sections for bug#8009 takes ~420ms! Without this refresh patch section creation takes ~1420ms for that same bug.
Excellent! I am noticing a huge difference when going through incomings.
Committed minor improvements to avoid unnecessary section expansion which saves a few reflows.
Very good improvements!
I'm very impressed too. This 25 comment bug took way less time to pop up then the tooltip for it did :)
I'm enjoying the speed improvements we've seen to date! Thanks again David for you input on this. Further improvements pushed to 3.0.
Rob, there is still issue with showing large comments (opened bug 219481 for that) and you can use bug 188524 as an example
no problem.... but it seems to me that you did all of the hard work!
Committed a patch to head (attached to bug 216677) that gets rid of form reflows during editor construction.
Created attachment 93904 [details] mylyn/context/zip
As I noted in bug 224009 this may also be related to using serialization to realize a deep copy, which is what the editor does. > To further the discussion I quote a bit from http://www.codeguru.com/java/tij/tij0127.shtml > [...] >Here is the output from three different runs: >Duplication via serialization: 3400 Milliseconds >Duplication via cloning: 110 Milliseconds > >Duplication via serialization: 3410 Milliseconds >Duplication via cloning: 110 Milliseconds > >Duplication via serialization: 3520 Milliseconds >Duplication via cloning: 110 Milliseconds >[...]
Deferring to 3.1. We will consider further performance improvements as part of the next release cycle.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
