Community
Participate
Working Groups
The goal is to see: 1.) Are we using significantly more memory than prior versions (discounting memory leaks)? 2.) If so, are there any ways to reduce this memory consumption? My methodolgy for the first phase is to do the following. Start with a fresh workspace, switch to the CVS perspective. Check out the platform-ui module. Switch to the Java perspective. Replace each project with the tagged version matching the running version. Import all other plug-ins as binary. Open ten editors. Activate my memory consumption action set, and check the memory after garbage collection.
Okay, it is too difficult to check out specific versions of a whole bunch of projects. Plus, some of platform-ui's projects did not exist in 2.1.3. Instead, I just check them out from HEAD. The ten files opened are the 5 files in the root of the org.eclipse.ui project, and the first five files in the org.eclipse.ui.commands package.
I do not change the VM's memory heap. It stays at default (i.e., 64MB).
Someone on the newsgroups said that memory consumption in Eclipse has gone from 100MB to 160MB. This is likely the result of memory leaks, which we are tracking down separately. The results listed below include a baseline value, which shows how much (percentage-wise) we've increased in memory consumption. To avoid out of memory errors, I had to switch to a 128MB heap size, rather than the planned 64MB heap. While the numbers all stay lower than 64MB after everything is complete, the earlier versions of Eclipse would generate peak heaps over the 64MB limit. All results from 3.0M4 and earlier use a 128MB heap size. 3.0M5 and later use 64MB. Release Eclipse Heap (MB) Heap Size (percentage) ------------------------------------------------------------ I200405111600 51 138 3.0 M8 51 138 3.0 M7 38 103 3.0 M6 32 86 3.0 M5 38 103 3.0 M4 40 108 3.0 M3 40 108 3.0 M2 36 97 2.1.3 37 100 Each test was only run once. I'd expect high standard deviation in the results. To get the results, the memory plug-in was copied into the installation, and the following was added to the platform feature: <plugin id="org.eclipse.ui.tools.memory" download-size="0" install-size="0" version="1.0.0"/>
so the question is what happened in M8?
The new look and feel happened in M8. PB
Need to find some help with this, it does not really seem to be UI related.
It doesn't? You've gathered data on this?
From the newsgroup: "It is piggish with memory, but RC1 is much improved for me in that regard, and I think that it is one of the issues they hope to address prior to the final release." You can follow the thread starting with "RC1 still a bit slow at times..", for some description of user experiences with memory consumption.
deferring, this is ongoing investigation but at this point there is not solid information on which to respond to.
I'm looking at this a bit more with regards to Scenario 43 of the WSAD performance work.
Eclipse ------- Starting Eclipse after the workspace is already built yields different compacted heaps. The compacted heap gets steadily smaller. 3.0 M7 58MB 3.0 M8 42MB 3.0 37MB This might indicate that the memory problems were actually related to leaks. I'm going to try to re-run my original test and see if the results are still skewed. WSAD ---- Starting WSAD 5.1.2 with the set-up from performance scenario 43 yields a 6 to 9 MB compacted heap. In the 6.0 integration builds, we see a 30 to 36 MB compacted heap. Hypothetical sources: all types cache, decorators, plug-in registry.
I re-ran my original test. It seems that the original discrepancy could be attributed to memory leaks introduced during M8, and fixed during the lead-up to 3.0. 49MB M7 63MB M8 48MB 3.0
