Community
Participate
Working Groups
There is a 1000% performance regression in the test NonInitialTypingTest#testTypeAMethod(). This is observed on both Linux and Windows. It seems to have started on 9th February. I am sorry that I missed catching this. :(.
(In reply to comment #0) > There is a 1000% performance regression in the test > NonInitialTypingTest#testTypeAMethod(). This is observed on both Linux and > Windows. It seems to have started on 9th February. I am sorry that I missed > catching this. :(. Since when is this?
(In reply to comment #1) > (In reply to comment #0) > > There is a 1000% performance regression in the test > > NonInitialTypingTest#testTypeAMethod(). This is observed on both Linux and > > Windows. It seems to have started on 9th February. I am sorry that I missed > > catching this. :(. > > Since when is this? Noticed from 9th February build.
I can reproduce a significant slowdown on Windows 7 - master Elapsed Process: 769ms (95% in [707ms, 830ms]) Measurable effect: 109ms (1.3 SDs) (required sample size for an effect of 5% of mean: 81) CPU Time: 917ms (95% in [812ms, 1.02s]) Measurable effect: 185ms (1.3 SDs) (required sample size for an effect of 5% of mean: 164) - 3.7.1 Elapsed Process: 389ms (95% in [342ms, 436ms]) Measurable effect: 83ms (1.3 SDs) (required sample size for an effect of 5% of mean: 182) CPU Time: 556ms (95% in [414ms, 698ms]) Measurable effect: 250ms (1.3 SDs) (required sample size for an effect of 5% of mean: 812) Looks to be another one of SWT/Display/events issue :-( I profiled using Yourkit and the invocation counts of "org.eclipse.jdt.text.tests.performance.EditorTestHelper.runEventQueue(Display)" are the same in both cases, however, the invocation counts of "org.eclipse.swt.widgets.Display.readAndDispatch()" are significantly different. This in turn causes the reconciler etc to run more times which causes the slowdown. This is what I think currently, continuing to investigate more...
I think the problem is the DefaultCharacterPairMatcher. The test types just in front of the last '}'. Since we now match on the left of the closing bracket, the matching bracket is updated all the time. In 3.7, we only matched the '}' on the left of the caret, so the DefaultCharacterPairMatcher always finished without doing anything.
(In reply to comment #4) Doh! I should have thought of that :-( I double checked the relevant time stamps - The code change was made on 2012-02-09 17:02:07 IST (bug 9503 comment 29) - The test started failing in the nightly build later the same day (http://download.eclipse.org/eclipse/downloads/drops/I20120320-0800/performance/eplnx2/Scenario108.html#CPUT) I will tweak the test to not type right next to a bracket and see if that fixes the problem.
(In reply to comment #5) > I will tweak the test to not type right next to a bracket and see if that fixes > the problem. Bracket matching was indeed the problem :-) I have tweaked the test to not type next to a bracket. http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=e98faed5bb3f143b029c3501093ed500073f6c35 With this change, the performance test numbers and invocation counts in YourKit are similar to 3.7.1.
> I will tweak the test to not type right next to a bracket I agree with that, but now the test types the method declaration outside of the class declaration, which is syntactically invalid and not a real-world scenario. Fixed by pressing Ctrl+Shift+Enter before typing the method: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=4b8bbff98ccf9f5c9422558a8f53d6ea93f91995
.. and reverted my bad change to MEASURED_RUNS: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=6444a8825b9e7422d30dfef1ee64206a632f8441
