Community
Participate
Working Groups
I20120320-1400 "Highlight enclosing brackets" still has performance problems: - in StyledText, put the caret to the beginning of the last method declaration - press and hold Shift+ArrowDown => selection updating is very sluggish
(In reply to comment #0) > I20120320-1400 > > "Highlight enclosing brackets" still has performance problems: > > - in StyledText, put the caret to the beginning of the last method declaration > - press and hold Shift+ArrowDown > > => selection updating is very sluggish With Version: 4.2.0 Build id: I20120315-1300 I do not observe a 'significant' difference in performance with and without the feature. I am not saying there is no difference, just that the difference is not significant, and calling selection updating 'very sluggish' may be a bit harsh :-) In any case, the problem does deserve another look.
When I hold Shift+ArrowDown in StyledText in my main workspace, I see the caret moving but the selection only follows up sporadically. In CleanUpTest, it's even worse. In the runtime workbench, it's not as bad, but it's still slower than with enclosing brackets disabled. YourKit says that in my main workspace, almost half of the time is spent in org.eclipse.egit.ui.internal.actions.RepositoryAction.selectionChanged(IAction, ISelection), and the rest is in our org.eclipse.jface.text.source.DefaultCharacterPairMatcher.findEnclosingPeers(..) => performance is still not good enough, but on our fast machines, it is acceptable unless something else also eats CPU cycles. A problem is that StyledText and TextViewer fire selection events for each selection change, but when the caret moves, there's only a post selection event from TextViewer.
(In reply to comment #2) > YourKit says that in my main workspace, almost half of the time is spent in > org.eclipse.egit.ui.internal.actions.RepositoryAction.selectionChanged(IAction, > ISelection), and the rest is in our I was not able to reproduce this. Markus, you had mentioned on chat that you will open a bug against EGit with more information. Did you already do that?
(In reply to comment #3) The other performance hog I saw was in org.eclipse.egit.ui.internal.actions.AddToIndexActionHandler#isEnabled() To reproduce, you need to: - have a workspace with many closed projects - enable the "Git" action set (via Customize Perspective... dialog) and show the Git actions in the toolbar Then, for each text selection change event, RepositoryActionHandler# getProjectsInRepositoryOfSelectedResources(IStructuredSelection) loops over all projects in the workspace and tries to find their repository provider, which takes a lot of time due to bug 375634. Once that bug is fixed, there's no relevant additional slowdown any more.
I did some more measurements and I didn't find anything more to optimize. Discussed with Dani and we decided that the current solution is good enough, also given that the enclosing brackets option is not enabled by default. If this turns out to be a problem in practice, we might have to move the updating into a post selection listener if we didn't find matching brackets after a screenfull of characters. Closing for now.
