Great, this is good news for Tiles. I will send you the analysis document under separate email. However, you will have to wait a little for the various tiles-config.xml files because I would need to obfuscate their content first (that, or wait for my manager's manager's manager's approval to disclose them ;). I am working on an important delivery for next week, so don't expect the obfuscated files before Tuesday or so.
Regards, -- Christophe -----Original Message----- From: Cedric Dumoulin [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 9:32 AM To: Christophe Warland Cc: '[EMAIL PROTECTED]' Subject: Re: Tiles excessive memory usage Hi, 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. Cedric > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
