Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 358490

Summary: [Commands] Performance test: OpenCloseViewTest
Product: [Eclipse Project] Platform Reporter: Oleg Besedin <ob1.eclipse>
Component: UIAssignee: Platform UI Triaged <platform-ui-triaged>
Status: RESOLVED FIXED QA Contact: Paul Webster <pwebster>
Severity: normal    
Priority: P3 CC: emoffatt, melickm, pwebster
Version: 4.2Keywords: performance
Target Milestone: 4.2 M6   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Bug Depends on: 358158, 358494, 359082    
Bug Blocks: 362718    

Description Oleg Besedin CLA 2011-09-21 16:47:46 EDT
The preliminary checks indicate that OpenCloseViewTest is about 6 times slower on 4.2 compared to 3.8.

The actual time to open and close a view on my Windows machines goes from about 70ms on Eclipse3.8 to about 400ms on Eclipse4.2.
Comment 1 Oleg Besedin CLA 2011-09-21 16:56:17 EDT
Note that profiler results are heavily skewed for this test. For instance, profiler indicates that EclipseContext#trackAccess() uses about 45% of the test time. 

This is not correct, direct measurement shows that median individual call time in this method is about 1,500 nano seconds. (Granularity of nanotimer on my computer is about 600 ns; it is usually assumed that System.nanoTime() own execution time is about 150ns.) At 20,000 calls per {open view, close view} this translates into ~30 milliseconds total time in the method, or somewhere around 1.5% of the test time.

This illustrates that profilers are rather inaccurate when dealing with large number of calls to relatively fast methods.
Comment 2 Oleg Besedin CLA 2011-09-21 17:03:30 EDT
From directly instrumenting code with #nanoTime() calls, we seems to have the following two bottlenecks:

MenuManagerRendererFilter#updateElementVisibility() - 45% of time
( bug 358494 )

HandlerSelectionFunction#compute() - 25% of time 
 (bug 358158 )
Comment 3 Oleg Besedin CLA 2011-09-26 14:12:25 EDT
From looking at the code, it seems that the time spend in menu/toolbar validations will increase at n*log(n) with the number of menu/toolbar items.
Comment 4 Oleg Besedin CLA 2011-09-27 10:03:38 EDT
Eric suggested to see what happens performance-wise if those two pieces of code is removed.

HandlerSelectionFunction#compute() return null	~30% improvement in CPU speed
MenuManagerRendererFilter#updateElementVisibility() returns right away	~40%
Both changed: ~about 40%

(I guess if we return "null" for all handlers when #updateElementVisibility() doesn't have much to do.)
Comment 5 Oleg Besedin CLA 2011-09-27 10:44:40 EDT
Next strange spot is ToolBarManagerRenderer$6.changed() which takes ~25% of the time (bug 359082).
Comment 6 Eric Moffatt CLA 2011-10-11 15:32:09 EDT
Nice work Oleg !
Comment 7 Oleg Besedin CLA 2012-03-28 15:41:09 EDT
At this time we are about 50% to 75% slower comparing 4.2M6 to 3.8M6.

This is a huge improvement, great work done by everybody!

To be continued in 4.3....