Hi, I support memory optimizations. The YourKit Java Profiler could help to find out what takes how much memory. If done correctly, memory optimizations will improve performance (because more items fit in the cache).
In addition to what Jukka proposed I would like to implement a value cache similar to http://java.sun.com/javase/6/docs/api/java/lang/Integer.html#valueOf(int) - even for Strings (using a SoftReference cache, not using String.intern). Regards, Thomas On Fri, May 16, 2008 at 5:55 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > On Fri, May 16, 2008 at 6:07 PM, Stefan Guggisberg > <[EMAIL PROTECTED]> wrote: >> On Fri, May 16, 2008 at 3:44 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: >>> * Remove memorized hashCodes from item ID's: 8MB ~ 3% >>> * Make NodeState.propertyNames a sorted list instead of a HashSet: 18MB ~ 7% >> >> there's the classic trade off of memory usage vs. performance. >> while the above modifications reduce memory usage they >> will negatively impact performance. > > Yep. > >> the amount of memory saved is significant, we'll have to find out >> how much it impacts (read) performance. > > The HashSet could be fairly easily optimized for memory without a > speed impact, since the java.util implementation just wraps a HashMap > that's quite a verbose way to store a set. A single array acting as > the hash table that points directly to the objects contained in the > set should be as fast (or even slightly faster) than HashMap while > using noticeably less memory. Of course it's extra code, so perhaps > something to propose for commons-collections. > >>> * Use a single InternalValue object instead of an array for >>> single-valued properties: 17MB ~ 7% >> >> impressive. i had chosen arrays in order to keep the code >> simple, i.e. avoid stmts like >> >> if (singleValued) { ... } else { ... }. >> >> but i guess that's not worth the extra memory overhead... > > An array with a single reference is something like 16-20 bytes, so it > adds up. There might be some way to cleanly avoid the if statements. > >>> * Use the underlying value objects directly instead of the >>> InternalValue wrappers in PropertyState: 18MB ~ 7% >> >> hmm, i'd be interested to see what exactly you've done >> to achieve this. don't you end up with long nasty >> switch/case stmts? > > I had to hack InternalValue a bit, basically add a public > InternalValue(Object data, int type) constructor so I could transform > back and forth between the data objects and InternalValues containing > them. Note that the type is already contained in PropertyState. > > Again, it seems like the InternalValue overhead is 16-20 bytes per > value, which is not too bad, but starts to show in aggregate. > > BR, > > Jukka Zitting >
