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