Community
Participate
Working Groups
Using RAD 7.0.0.1 - which uses org.eclipse.jdt.debug_3.2.2.r322_v20070130 instrumented jdt.core plugin to measure ClasspathContainerInitializer initialization durations. scenario: start RAD against a 110+ J2EE projects and collect average ClasspathContainerInitializer initialization durations the JREContainerInitializer takes more time than others. Initializer com.ibm.ws.ast.st.core.internal.runtime.ServerClasspathContainerInitializer@3b543b54 initialized 90 times Total duration: 260 ms Average duration: 2 ms Initializer org.eclipse.jst.server.core.internal.RuntimeClasspathContainerInitializer@640064 initialized 108 times Total duration: 190 ms Average duration: 1 ms Initializer org.eclipse.jdt.internal.launching.JREContainerInitializer@5b605b60 initialized 116 times Total duration: 1873 ms Average duration: 16 ms this init duration might have an impact on startup times.
Eric, when we tried this test by launching into the J2EE perspective on startup, the classpath initializers were running off the scale. The initialers ran numbers times (8-9times), and their respective durations became longer. Here's the result for the JREContainerInitializer: Initializer org.eclipse.jdt.internal.launching.JREContainerInitializer@76f876f8 initialized 42 times Total duration: 23122 ms Average duration: 550 ms Would it be possible to try launching your 100+ project workspace into the J2EE perspective and confirming my results? Thanks!
(In reply to comment #1) Seng, had another test run using a more recent version and obtained an average init time of 98 ms for the JREContainerInitializer. Performed 12 warm startup runs. I'll send you the raw data and you'll notice that init time can vary from 20 to 298 ms ! though I was just starting / stopping RAD
Marking as P1, as this slows down startup.
Applied a fix to StandardVMType where we were looping over lots of loops many times causing a fair amount of work. Now we iterate over the collect once. Took about 2 seconds out of startup work. Other findings: JavaCore.newLibraryEntry(IPath, IPath, IPath, IAccessRule[], ClasspathAttribute[], boolean) is a very expensive method (as seen in the first attached screen shot), which seems to be causing a fair amount of startup work
Created attachment 63099 [details] screenshot Shows JavaCore.newLibraryEntry(...) and the amount of work out of the totals it actually does. Notice in the cases shown in the screenshot it does more than half of the work each place it is called, although it does have a high invocation count (and each invocation is less than 1ms), this might be worth looking at, maybe we can cut down on the the number of calls to it.
Created attachment 64105 [details] patch Work in progress. When access rule participants always return the same set of rules, we can cache/reuse classpath entries. However, when access rule participants don't return the same set of access rules, this cache just grows (bad).
Created attachment 64230 [details] further work in progress Worked on what you provided so far, profiled the heck out of it and made a few changes. We are now down to 32 invocations for JavaCore.newLibraryEntry, and have dropped almost 5 seconds off of the profiled timings. Darin, have a look at the new code and see if you can see any more places to squeeze blood out of this stone :). Will post screenshot of latest profile session with this patch applied.
Created attachment 64232 [details] screen shot newest profiling session showing 3 second improvement in the JREContainerInitializer#initialize timing over the original profiling session (the first screen shot)
Looks good. Comments: * ExecutionEnvironment needs to be a VM listener to clear its caches as VM's change/remove. * In ExecutionEnvironment we use equals(..) on a Map to test whether to re-use the cached access rules. However, we are relying on identity of the IAccessRule[][] arrays. We could do extra processing here in case rule collections are equal but not identical? (similar to what we do in the JREContainer).
Released changes to HEAD including making the ExecutionEnvironment containers VM listeners so they can update more appropriately. Subsequent profilings show the performance steady in line with the last screen shot. Changes to ExecutionEnvironment and JREContainer
Darin W please verify the changes and the performance changes.
(In reply to comment #10) Darin, any chances we could backport this one to 3.2, so that other eclipse based products (like RAD) could benefit it?
+1 for 3.2 backporting
Is there a performance problem in 3.2? We did not support access rules on execution environments in 3.2 - that was new in 3.3.
(In reply to comment #14) Please refer to the initial comment when openening this bug. RAD 7.0.0.X uses org.eclipse.jdt.debug_3.2.2.r322_v20070130
Re-opening. Looks like there's more work to do here in terms of JREContainerInitializer.resolveVM(..).
After more profilings and further testing the performance between 3.2.2 and 3.3 is almost identical when execution environments are not used for the 100+ projects. If however execution environments are used there is an appreciable timing difference, as we have to do more work. We have mitigated this difference as much as we can by creating a new caching scheme for access rules in 3.3. The invocation count issue mentioned in comment 16 was due to a mis-configuration between my 3.3 and 3.2.2 workspace. Once that was fixed the profilings were identical (as they should be since that code has not changed). remarking as FIXED.
Darin, please re-verify the findings.
reopening to reassign
Darin W, do your thing
Verified.
