Community
Participate
Working Groups
org.eclipse.jdt.text.tests.performance.ActivateJavaEditorTest#testActivateEditor() results are over 10% regression since the beginning of 3.4 (between -13% and -131%). The standard error of this test is always over 3% (between 3% and 10%) but the regression is systematically bigger, hence this regression needs to be investigated. Note that this test lasts enough (around 4 seconds) to make this regression noticeable by users...
Benno please investigate.
The reason for this is that we create around 20% ASTs then we did in 3.3.1.1 during this test. All those ASTs are created by the ASTProvider and requested by SelectionListenerWithASTManager. SLWAM does request the ASTs with flag WAIT_ACTIVE_ONLY which says: Wait flag indicating that a client requesting an AST only wants to wait for the shared AST of the active editor. ***No AST will be created by the AST provider.*** Hence no ASTs must be created by the AST provider during this test.
Created attachment 88418 [details] fix Proposed fix. Dani, the ASTProvider is complex, can you please review? I can guarantee that this will make the test green again;-)
sorry, it should read: around 20% _more_ ASTs. The point is that the ASTProvider calls ASTParser#createAST although the request flag is WAIT_ACTIVE_ONLY and therefore only the reconciler AST should be returned. The fact that there is no such AST when requested may be another bug. Hint that this bug is also in 3.3.1.1
>***No AST will be created by the AST provider.*** This is a bug in the doc. The AST for the active editor will be created in case there's no reconcile and it's the active editor. Reconcile on activation only happens when there was a change while the editor wasn't active. I could not reproduce when activating editors manually i.e. on each activation exactly one AST gets created. I now have to check using the test case itself.
Looked at the test output and it looks OK regarding AST creation: it creates as many AST's as there are runs because the AST creation gets cancelled. Hence it depends where you've put your println statement.
(In reply to comment #6) > Looked at the test output and it looks OK regarding AST creation: it creates as > many AST's as there are runs because the AST creation gets cancelled. Hence it > depends where you've put your println statement. > Not on my machine, between 6 and 8 ASTs are create on each run. The reason for the regression is that more ASTs are created.
One part (100-300ms / depending on machine) is caused by the following bugs: - bug 232499: Slower image painting due to fix for bug 224422 and bug 219432 - bug 232489: [Contributions] Switching editors updates TooItems updated due to calls to org.eclipse.ui.menus.CommandContributionItem.updateIcons() - bug 232513: [Commands] *Authority classes taking up more time than they did in 3.3 There is however a bigger on in our land (need to verify Benno's comments).
Comment 6 was wrong: they aren't canceled. Under normal conditions each editor activation will trigger one AST to be created. Now, this test activates 30 editors in a loop without pause and if the next editor is activated before the previous one sent out the selection changed event, no AST is requested by our SelectionListenerWithASTManager. Now, in 3.4 editor activation is slower (see comment 8 and normal text editor activation perf test) and hence the selection event is processed more often and hence more ASTs are requested. ==> this test is unreliable. The correct fix is to wait for the AST to be available. Doing this revealed two quite old bugs (bug 233953 and bug 233954) which might be too risky to fix at this point. I've adjusted the test and moved it off the local fingerprint/summary for now (see bug 233955).
Verified through code inspection that the test is disabled.
