Community
Participate
Working Groups
Looking closely at Scenario Status Table of JDT/Debug component, I saw that the scenario testContextualLaunchMenu() of org.eclipse.jdt.debug.tests.performance.PerfContextualLaunchMenu got a noticeable regression since build I20070925-0800. Here are the numbers: RHEL 4.0 Sun 1.4.2_10 (3 GHz 2.5 GB): -118.6% [±13.3] Win XP Sun 1.4.2_10 (3 GHz 2 GB): -45.1% [±10.0] RHEL 3.0 Sun 1.4.2_10 (3 GHz 2 GB): -30.6% [±6.6] Win XP Sun 1.4.2_10 (2 GHz 512 MB): -121.7% [±39.6] RHEL 3.0 Sun 1.4.2_10 (2 GHz 512 MB): -21.7% [±17.9] Even if the standard error is quite big, the results are still negative using the optimistic value (results+|stderr|)... Sorry for reporting this so late, but I missed it as this was not a fingerprint test...
Investigate for 3.4
Marking as M7 (although, we do need preformance tests to run again :-)
Performance was degraded after we fixed Bug 181204 (contextual launching of non-resource based objects). We added the following code to ContextualLaunchAction.fillMenu(): in 3.4 we are correctly passing the IEditorPart and ISelection, so we have to perform some sneekyness to make sure the IEditorInput is passed to the eval expressions for backwards compatibility Object o = ss.getFirstElement(); if(o instanceof IEditorPart) { selection.set(0, ((IEditorPart)o).getEditorInput()); } When I took out this code and reran the test, the fillMenu() method took about half the time.
Marking as fixed. The problem is that this test was improved 10x during 3.3 (vs 3.2). The test went from @500ms to @50ms. This test has become so much faster that it is unreliable. In 3.3, we could fill the context menu 40 times in 61ms. In 3.4, we can fill the context menu 40 times 81ms. This is not a real degradation - the menu is less than 1ms slower to fill. I have added a comment to the test, and we will replace or remove the test in 3.5.
Closing.
