Community
Participate
Working Groups
Running performance test FullSourceWorkspaceASTTests#testWkspDomAstCreationJLS2, it appears that around 26,000,000 calls to EclipsePreference#get are done. This can be improved greatly by caching option of IJavaProject which will avoid to ask many times JavaCore options and compute map of project options.
Fixed and released in HEAD. No specific test case added as this optimization is verified by performance tests FullSourceWorkspaceSearchTests#testIndexing and FullSourceWorkspaceASTTests#testDomAstCreationJLS2.
Do you have any idea of how many calls are saved?
yes. In Eclipse 3.0 full source workspace, there are 57 projects, 9402 units and each java project has 336 options set. In this test all units are parsed and 2 getOptions(boolean) is called per project. Without optimization, getOptions(boolean) calls EclipsePreferences#get twice per option. So, we got exactly 9402 x 2 x 336 x 2 = 12,636,288 calls. Finally we have to multiply these calls by 2 as indexer was also running while executing this test => 25,272,576 calls. With the optimization, getOptions(boolean) calls twice EclipsePreferences#get method for each option only once per project. That means that number of calls is now 57 x 336 x 2 = 38,304 calls => 25,234,272 calls are saved in this test case...
Could not be verified. Performance tests are ok. Verified in I20050510-0010 + JDT/Core v_556
Verified for 3.1 M7 using build I20050512-2035 + jdt.core HEAD. (Traced a gain 10602292 -> 60076 on org.eclipse.jdt.core.tests.dom.RunAllTests.)