Community
Participate
Working Groups
Compare to 2.1.3, RC1 is much slower. RC1: - 20s for java.lang.Throwable - 2 min 45s for java.lang.Object 2.1.3: - 6s for java.lang.Throwable - 54s for java.lang.Object I used the big workspace for a test case. I had to fix some errors prior to make some benchmarks.
After building the same workspace on both 2.1.3 and RC1, I finally got result that are closer to each other. 2'22" for 2.1.3 3'39" for RC1 My workspace contains all projects from the R_2_1_maintenance branch + all required projects version R_2_1_3. You need to fix the .classpath of the swt project and I also added org.eclipse.update.ui.win32 project. You end up with 143 projects.
The last two times are for the java.lang.Object hierarchy. I am running a JDK1.4.2_04 VM.
Using the same workspace, the time for the Throwable hierarchy is: - 7s using 2.1.3 - 16s using RC1
This may be caused by the fact that the hierarchy in 3.0 contains anonymous and local classes.
I'm investigating using OptimizeIt and YourKit Java Profiler tools...
Unfortunately I cannot use YourKit for this comparison as it seems not possible to run it as a 2.1.3 plugin... :( So, with OptimizeIt my first try on a 2.1.3 workspace containing 71 projects does not show real difference between two versions. Opening hierarchy on Object: 1) 2.1.3: 100.0% - 68349 ms - org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.doHierarchyRefresh() 2) 3.0: 100.0% - 66186 ms - org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.doHierarchyRefresh() I will repeat these measurements several times to verify their accuracy... Note that for this measure: 1) I start CPU profiler only when Open Hierarchy Dialog is opened and object selected, 2) I've activated 'Show Super Type Hierarchy' instead of 'Show Type Hierarchy' This scenario help me to avoid measure built of UI objects...
I've made two additional tests per version: 1) Workspace with jdt-core plugin and all its prerequesites loaded in workspace => 7 projects 2) Workspace with pde-ui plugin and all its prerequesites loaded in workspace => 38 projects Full detail of these tests will be in zip file I'll attach after... I have summarize most important times: A) Version 2.1.3 test 1 - 7 projects ModalContext$ModalContextThread.run(): 93.56% - 9634 ms BinaryType.newTypeHierarchy(): 80.64% - 8304 ms TypeHierarchy.addTypeHierarchyChangedListener(): 12.91% - 1330 ms Audit.main(): 6.24% - 643 ms FocusOnTypeAction.run(): 6.19% - 638 ms TypeHierarchyViewPart.setInputElement(): 5.40% - 557 ms TypeSelectionDialog.open(): 0.78% - 81 ms test 2 - 38 projects ModalContext$ModalContextThread.run(): 95.07% - 31005 ms BinaryType.newTypeHierarchy(): 75.78% - 24713 ms TypeHierarchy.addTypeHierarchyChangedListener(): 19.29% - 6292 ms Audit.main(): 4.76% - 1555 ms FocusOnTypeAction.run(): 4.76% - 1555 ms TypeHierarchyViewPart.setInputElement(): 4.41% - 1439 ms TypeSelectionDialog.open(): 0.35% - 116 ms B) Version 3.0 test 1 - 7 projects ModalContext$ModalContextThread.run(): 83.36% - 4075 ms BinaryType.newTypeHierarchy(): 80.64% - 8304 ms TypeHierarchy.addTypeHierarchyChangedListener(): 12.91% - 1330 ms Audit.main(): 15.22% - 744 ms StructuredViewer.update(): 8.14% - 398 ms FocusOnTypeAction.run(): 7.07% - 346 ms TypeHierarchyViewPart.setInputElement(): 4.90% - 240 ms TypeSelectionDialog.open(): 2.16% - 106 ms test 2 - 38 projects ModalContext$ModalContextThread.run(): 73.88% - 16328 ms BinaryType.newTypeHierarchy(): 73.88% - 16328 ms Audit.main(): 25.46% - 5627 ms StructuredViewer.update(): 19.11% - 4223 ms FocusOnTypeAction.run(): 6.35% - 1404 ms TypeHierarchyViewPart.setInputElement(): 5.91% - 1306 ms TypeSelectionDialog.open(): 0.44% - 98 ms These results shows that for 38 projects: 1- time to build hierarchy was divided by 2 (31005 ms -> 16328 ms) 2- time to display it was multiply by 3 (1555 ms -> 5627 ms) I guess that with 143 or more projects the ratio is perhaps more important than that. unfortunately, OpitmizeIt didn't authorize me to perform tests with more projects as it crashes over this limit... Move to Platform/UI for comment as it seems that additional time comes StructuredViewer.update()...
Created attachment 11960 [details] Details of CPU profiling for all tests
Great stats Frederic. Good that our computation is twice as fast as it used to be.
Billy I have been looking at this one but I haven't been able to replicate the sort of benchmarks that Frederic has
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
We should rebench this case with the PerformanceStats as well.
Are there work items left for this PR?
Likely no as the JDT team has implemented something new. I will leave this open until the new types view is the main one.
New type selection dialog has been released so this is now obsolete.
