| AW: [rap-dev] RAP memory consumption |
|
Hi all, I found something at http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#101083
chapter 3.10.5 String Literals. At the bottom of the chapter: ·
Strings computed at run time are newly created and therefore distinct. · The
result of explicitly interning a computed string is the same string as any
pre-existing literal string with the same contents. If I understand the proposal below and the specification correctly
the duplicate widgetId Strings could be avoided by changing the IdGenerator#newId()
method to String newId() { lastId++; return new StringBuffer( "w" ).append( lastId ).toString().intern(); } Despite the mentioned performance problem of the 1.4 JVM I somehow
tend to prefer this solution over something else.. So we used StringBuffer for String concatenation to avoid performance
problems and got more memory consumption instead. Great. Before we 'optimize'
the IdGenerator the proposed way, we should ensure that this is not performance
critical, because performance prevails memory consumption in that case. But as
the widgetId is computed only once in a session I don't expect a huge impact. Ciao Frank Von:
rap-dev-bounces@xxxxxxxxxxx [mailto:rap-dev-bounces@xxxxxxxxxxx] Im Auftrag
von Frank Appel Hi, is there any literature available regarding the duplicate
Strings problem? I ask this because to my knowledge Strings are unique
within a VM and there's nothing I found by a quick search in the web that
differs from this statement (Maybe I used the wrong query words…): "The JVM recognises that the two string literals are
identical and only creates a single instance. This is sensible on the part of
the JVM for performance and memory reasons" So it would be great, if someone has a link that describes
how this problem can happen. Ciao Frank Von:
rap-dev-bounces@xxxxxxxxxxx [mailto:rap-dev-bounces@xxxxxxxxxxx] Im Auftrag
von Jochen Krause Hi, Yesterday I had a memory analyzing session with an expert
from the Eclipse Memory Analyzer team. We had a look at a heap dump of the RAP
Demo Application with a couple of hundred simulated users. Here are the most important results: Memory consumption of the RAP framework is very reasonable!
This is a great result. Still, there is always some room for improvement: There are many duplicated Strings. A big chunk of those are
from widget ids. Moving the implementation to use String.intern() will probably
be a quick and efficient way to improve memory consumption (only the S.. JVM
1.4 is inefficient with String.intern() ). Another alternative might be using our
own data structure, if we restrict ourself to UTF-8 we need only 1 Byte per
character instead of 2 Byte for String. Another area for potential improvement is our use of
Hashmaps, We have 172.000 completely empty hashmaps (530.000 in total). It seems that WidgetAdapter is contributing significantly to
the large amount of empty hashmaps. From my point of view this is not high priority at the
moment, but could be researched in one of the upcoming releases. Jochen P.S: See also the interesting posting here: |