jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Müller" <thomas.muel...@day.com>
Subject Re: Memory use of item states
Date Tue, 20 May 2008 12:30:53 GMT
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 <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On Fri, May 16, 2008 at 6:07 PM, Stefan Guggisberg
> <stefan.guggisberg@day.com> wrote:
>> On Fri, May 16, 2008 at 3:44 PM, Jukka Zitting <jukka.zitting@gmail.com> 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
>

Mime
View raw message