struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cedric Dumoulin <>
Subject Re: Tiles excessive memory usage
Date Wed, 12 Mar 2003 14:31:50 GMT


Christophe Warland wrote:

>With regards to the methodology used, simply start your JVM with "java
>-Xrunhprof:heap=sites ..." and look at the self-explanatory results in
>java.hprof.txt. I can also send you, Cedric, our detailed analysis under
>private email if you agree not to distribute it. 
  What I am also interested in is the huge tile-config.xml files 
containing the 668 definitions and there attributes ;-). This could save 
me a lot of times . Of course all the documents that you can send me 
will fit under the NDA.

>Alternatively, you can also follow me through this enlightening theorical
>discussion. (The stats gurus amongst you are welcome to step in and correct
>me; from here on, I am only trying to show off and look smart :)
>As our example showed, just for one attribute, we ended up with 668 entries
>instead of one. For all the attributes in our system, we can use the
>following model: 
>  if 'n' is the number of Component Definitions, 
>     'K' is the total number of all the attributes, and
>     'd' the average depth of inheritance, 
>  let's further call 'm' the average number of inherited attributes per
>Component Definition, with m being conceptually equivallent to (K/n)*d,
>  then we end up with instantiating (n*m)^d HashMap$Entry objects instead of
>only 'K'. 
>That is (n*m)^d instead of n*m/d. Exponential square instead of linear!
>To put that in perspective, our production app yields the following values:
>  n = 668
>  K = 7037
>  d = 1.57
>  m = 16.5
>And we get (668*16.5)^1.57 = 2,219,978 HashMap entries instead of the more
>intuitive 7,037 (= K). Since, one HashMap entry takes 24 bytes in memory,
>this represents my loss of 50 MB (see previous email).
>*Had* we developped an application with the same amount of Component
>Definitions and attributes but with a higher average depth of inheritance,
>for example d=2 instead of d=1.57, this model shows that we would have
>needed 4.5 GB of RAM just to load Tiles. 
>This number looks ridiculously high, so my mathematical model is probably
>wrong. However, keep in mind that our app does need an extra 50 MB of RAM
>just to load 7037 attributes, which is ridiculously high too. So this
>exponential equation might not be too far from the truth.
  Ok, you convince me that in case of very large application like yours, 
the actual inheritance implementation can be improved in order to reduce 
the amount of memory used.

>The bottom line is, Tiles does not scale for us. YMMV. We found a fix that
>works for us and we wanted you to be aware of it. Feel free to use it or
>drop it. And again, keep in mind that our analysis is based on Tiles
>2001-09-10, so this misbehavior might not be present in the latest Struts
>1.1 RC#.
  The inheritance mechanism hasn't change in this way, so your analyze 
still actual.

>Back to your email, Cedric, it is also very much possible that we misuse
>Tiles. You say that we could "avoid the map creation in the contexts when no
>locale attributes are set." Could you elaborate a little? Thanks.
  I say that we can easily modify the actual implementation to avoid 
systematic creation of a hashmap in each new context. We can create the 
hashmap only if needed (i.e. when an attribute is added to the context 
by the way of <insert ...><put ../></insert>). Otherwise, we store the 
definition hashmap reference, and use it to retrieve existing attributes 
(but not to store new ones).
  This will not solve the problem of the inheritance mechanism. Here we 
need to implement a mechanism like the one you propose: Don't 
systematically copy parent attribute entries in the child definitions, 
but use the parent attribute maps instead.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message