Community
Participate
Working Groups
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.
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.
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 )
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.
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.)
Next strange spot is ToolBarManagerRenderer$6.changed() which takes ~25% of the time (bug 359082).
Nice work Oleg !
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....
