Community
Participate
Working Groups
Build: I20050315 The watchful performance eye took a peek today at the memory footprint of the preference service. My test case was to start a workspace containing all platform core projects. I opened every preference page, and then selected a project and opened every property page. It looks like the preference tree occupies about 500KB at this point. The DeepSize tools shows the following memory usage (deep size of PreferencesService.root, ignoring listener lists): org.eclipse.core.internal.preferences.InstancePreferences size: 4200 java.util.Properties size: 2160 org.eclipse.core.runtime.Path size: 1160 java.util.Collections$SynchronizedSet size: 16 java.util.HashMap$EntrySet size: 312 java.util.HashMap$KeySet size: 12 java.util.Hashtable$HashtableEntry size: 38160 java.lang.String size: 82896 [Ljava.util.HashMap$Entry; size: 2488 org.eclipse.core.internal.preferences.DefaultPreferences size: 1400 [Ljava.lang.String; size: 1688 java.util.HashMap$Entry size: 3336 org.eclipse.core.internal.resources.ProjectPreferences size: 2176 java.util.HashMap size: 1144 org.eclipse.core.internal.preferences.RootPreferences size: 48 java.util.Collections$SynchronizedMap size: 728 org.eclipse.core.internal.resources.File size: 272 [C size: 370558 org.eclipse.core.internal.resources.Project size: 240 [Ljava.util.Hashtable$HashtableEntry; size: 16224 Total size of all objects: 529218 Observations: - The main data structure for the preferences is a Properties instance (subclass of Hashtable). Could consider a more efficient Map implementation. - There is some string duplication. Putting every string in a StringPool yields a memory savings of 119,742 bytes (about 25% of the total memory of the strings).
At one point I had looked at using an ObjectMap for the property key/value pairs. I elected to stick with the Properties because that is the object type that is used for serialization. But since we use a separate Properties object to gather results before writing it to disk, I don't think that there is anything stopping us from changing this. Also note that I am considering getting rid of the listener registry and moving the listener lists (both node and pref change) to the nodes themselves. (bug 89262)
Initial testing finds that converting to use ObjectMap rather than Properties and sharing the strings roughly cuts memory usage in half. In my workspace I forced all preferences to be loaded by using the preference stats view. String sharing brought the size from 1,501,250 bytes to 864,460, a 620KB savings!
It turns out that JDT core was leaking some very large strings in the preference store (Bug 89850). Once that is fixed, the advantage of string sharing might not be as large. I'll test again once the JDT core bug is fixed.
Released the change to use ObjectMap instead of Properties, and added code to periodically perform string sharing. As already mentioned, this saves 620KB of heap space in my large self-hosting workspace (core, ui, core tests, doc). I created a more realistic test case with a small number of projects (six). After starting in the Java perspective, and performing a full build of the workspace, the string sharing pass saved 180 KB of heap.
