Community
Participate
Working Groups
Consider 1000 content types a reasonable worst case scenario. How much memory is consumed? How long does it take to find content types based on file names/ contents?
The following improvements were performed so far: - reduced footprint for content description objects (bug 61976) - caching content descriptions when IFile#getContentDescription is used, default content descriptions are shared (bug 58726) Keeping this PR open to track any further work on performance.
Another performance fix: bug 61975.
Created attachment 17958 [details] patch for org.eclipse.core.tests.runtime The patch contributes some performance tests for the content type infrastructure. Running the tests, I could not see any excessive performance costs while doing regular operations such as content type matching (by name or content) and content type inheritance checking when the platform contains more than 1000 content types. Once the patch gets released to HEAD, perf_30 and perf_301 branches, I will close this PR.
DJ, these are changes that only affect the performance tests (test addition). Should I still wait until M5 is out or can I release it now?
If the core code is already released and its only a test change, then feel free to release.
Ok. Released to HEAD/M5, 3.0 and 3.0.1 performance testing branches. Closing.
This could use more work during M7. Need to: - investigate why performance tests are failing (measuring done wrong in the 3.0.1 tests?) - add performance monitoring using new PerformanceStats API - make sure new features (bug 69640 and bug 87447) don't cause performance regressions See also related bug 89287.
Things to look into: - consider merging the validation/description stages - at least optimize the case where one single content type is eligible - improve XMLRootElementContentDescriber (stop using XML parser) See also bug 89195 comment 23.
Minor improvement (memory footprint): XML files with explicit UTF-8 encoding manifested in the <?xml?> processing instruction are treated as if no encoding was explicitly specified. This increases the chances the same default content description object can be used for most XML files.
Run out of time for M7. If the required changes end up not being very extensive and the performance improvements prove to be worthwhile, I will try to get approval to do this after M7.
Created attachment 21231 [details] patch for org.eclipse.core.runtime This patch implements the idea of doing a single pass of validation/description if only one content type matches a file name (*.java case). It also will short-circuit the case where no content type matches a file name specification (we were doing some unnecessary work in this case).
DJ, do you approve the changes to org.eclipse.core.runtime? They are very localized and there are no relevant changes to behavior.
+1 for RC1
Released patch. Also, I opened bug 92617 to address the fact we use a full fledged SAX parser for content type matching, but I don't think that will be addressed for 3.1. Will close this PR as soon remaining issues (failure in workspace content description performance tests) are investigated.
The test failures are due to the fact that an unrelated test project contributes many more content types in 3.1 than used to in 3.0. Running without that project, actually shows that we are slightly faster in 3.1 (~7% in the cold test, ~3.5% in the warmed up test). I am disabling those tests for now. Need to devise a way to run them in separate, as a session test for instance. Closing. All the work planned for 3.1 is done. Any specific issues should be addressed in a separate PR.
