Hi,
Christophe Warland wrote:
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.
[...]
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.
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.
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.
The inheritance mechanism hasn't change in this way, so your analyze still actual.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#.
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).
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.
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.
Cedric
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
