Community
Participate
Working Groups
After I20050610, it seems that CreateTypeHierarchyOperation has become significantly slower (around 20%). Although JDT UI has done some improvements in the rendering code, our performance test org.eclipse.jdt.ui.tests.performance.views.TypeHierarchyPerfTest#testOpenObject Hierarchy2() (Win XP Sun 1.4.2_08 (2 GHz 512 MB)) is 24% red Doing a diff on traces for M7 and I20050624 shows that the performance loss originates in CreateTypeHierarchyOperation#execute Attaching traces
Created attachment 23933 [details] trace for M7
Created attachment 23934 [details] trace for I20050624
We also have a test for type hierarchy performance and it's the most stable of our performance tests. Have a look at http://fullmoon.torolab.ibm.com/downloads/drops/S-3.1RC3-200506171618/performance/org.eclipse.jdt.core.php? JDT/Core performance tests results for RC3, test "Type Hierarchy>All Types" never vary more than 4% on all test boxes since I20050506 (2 of them variation is less than 1%). This test get all classes for org.eclipse.jdt.internal.compiler.ast.ASTNode which is 154 classes. Note also that your test is only red on this performance test box. It is OK on other ones. So, all these observations would imply that JDT/Core code is not really involved there (otherwise how this test result can be OK on other test boxes?)... Last point about differences with your Yourkit traces, we already noticed that yourkit time measuring is specially bad and should not be used to compare performances...
I also had a look at the JDT Core performance tests. However, there are a few differences: - JDT Core averages the results over several runs, the test mentioned in comment 0 is a warm test measured only once after the cold one - JDT UI creates the type hierarchy on java.lang.Object to get reasonable input for the rendering code It's true that the performance test is only red on the slower windows box. Since the performance constantly seems to be slower since shortly before RC2, it may be worth to have a look at it, since the scenarios surely are quite different.
Finally, it seems that you point a real problem Tobias... This is a side effect of bug 98378 fix. We also need to add some test in FullSourceWorkspaceTypeHierarchyTests to be able to see this kind of changes.
Created attachment 23945 [details] Changed IndexBasedBuilder#createInfofFromClassFileInJar(...) to use the OS path in the case of external jars
Tobias, can you please run your test with this patch and let us know if it improves things ? Thanks.
If we do not address it, opening type hierarchies on Win32 needs more memory/CPU time than it should (explains perf regression on JDT/UI perf test for type hierarchies, could also cause some out of memory issues on small configs). Badness got introduced in RC3 as a side effect of addressing 98378 (regression from 3.0), it changed one path format, and one client site didn't get updated, fix is quite simple as the path change is similar to what we do on other client sites.
Created attachment 23949 [details] performance results with reboot
Created attachment 23950 [details] performance results without reboot
On one shot is really difficult to say if your results are correct. My perf tests experience shows that deviation may be really important... Here's a sample, I've run your test with an without patch 5 times each and get following results: Without patch test1 test2 test3 3.14 921 561 1.6 802 541 1.66 851 581 1.6 602 831 1.48 811 582 With Patch test1 test2 test3 1.68 580 481 1.61 671 531 1.55 620 510 1.66 581 571 1.62 601 741 My conclusion will be that patch globally solves the problem. Problem you see with warm test is surely due to "normal" results variation on your machine (I guess you done it on WinXP?) As you can see on 5 iterations we got variation of 30% and 50% for small duration tests!
Yes, this is also my impression. Based on the measured results (under WinXP), the patch in general seems to fix the performance regression. The performance gap between the cold and warm performance tests on java.lang.Object are noticeable in RC1 as well (less caching), so the results show that the fix is effective.
Dirk - pls vote
Dani - pls vote
+1 for RC4.
+1 for 3.1 RC4
Thanks. Released patch from comment 6.
Verified that performance are fine again. Performance tests will validate this one later. Verified with I20050624-1300
