Thanks Christophe. I will take my time seeing what youve done and to see how it best fits to 1.1. I would like to hear from Cedric too as soo as possible to be sure there's ot something we've missed. If I have succes with 1.1 I'll be sure to offer it to this mail list But I truly hope to hear from Cedric before I move to far ahead.
Thanks agin, Chris ----- Original Message ----- From: "Christophe Warland" <[EMAIL PROTECTED]> To: "'Struts Developers List'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, March 10, 2003 7:00 PM Subject: RE: Tiles excessive memory usage > Patch is attached. Once again, please note that this is based on Tiles as of > 2001-09-10. I would send my sources to the list, but I have only just joined > struts-dev today and I don't know the etiquette in use here with regards to > attachments. FWIW, my modified sources fit in a 17k zip file > (non-uuencoded). > > If you are not interested in my patch and prefer to implement it your way, > here is my advice: > 1. go to ComponentDefinition and ComponentContext and delete the following > 'evil' methods > public Map getAttributes() > public ComponentContext(Map attributes) > public void addAll(Map newAttributes) > public void addMissing(Map defaultAttributes) > 2. then refactor/recompile/refactor the rest of Tiles until you have > something usable (pass along and keep track of ComponentDefinition objects > as much as you can -- never access the HashMap directly). > > Regards, > > -- Christophe > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, March 10, 2003 6:22 PM > To: Struts Developers List > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Tiles excessive memory usage > > > Chris, > > I'm just now getting to profiling our struts/tiles app and have always had > some concern about the efficiency of the tiles. Not that I'm a suspecting > type of person but I just didn't have any information and that caused me to > wonder. > > Regardles when or if this fix gets placed in a release, would you be willing > to offer sufficient code snippets that will give me enough understanding to > implement your fix in my app? I'm now getting deeper into tiles and getting > a good feel for what's going on so this would be a perfect time for me > before we enter client phase. Also, I'd be willing to contribute this > efficiency gain to the project(with your help or ok) if Cedric and the other > powers agree this is something that should be done. > > But in the meantime, could you supply me with some more detailed information > and snippets. This could potentially kill my project since performance is > the major hot word amoung manager types these days where I work. You can > reply to [EMAIL PROTECTED] with details that don't pertain to the > developer's group if you like. > > Thanks for posting this!!!!!!! > > Chris Willingham > ----- Original Message ----- > From: Christophe Warland > To: '[EMAIL PROTECTED]' > Cc: '[EMAIL PROTECTED]' ; '[EMAIL PROTECTED]' > Sent: Monday, March 10, 2003 4:47 PM > Subject: Tiles excessive memory usage > > > At my company, we have been recently forced to patch Tiles to solve some > major memory problems where Tiles was eating a lot of memory for no apparent > reasons. We wish to share our findings with you. And we will be happy to > send our code change to Cedric if he wishes so. > > Here are some quick numbers about our J2EE runtime after complete bootup > (appserver and EAR file are up, deployed and ready to serve HTTP requests): > - With original Tiles code: 79 MB of RAM is used > - After our custom code change: 28 MB of RAM is used > > Note that the Tiles version that we use is an old one (our source zip > shows 09/10/2001). However, a quick analysis of the more recent Tiles source > found in Struts 1.1 RC1 shows that most the code where the defect lies is > still in there. But we haven't actually been able to confirm the problem at > runtime since our app is not compatible with the latest Struts and Tiles > development. > > Here are a few excerpt of our internal analysis so that you can understand > the issue. > > -- > > Our application does not actually make use of the Tiles template mechanism > but instead builds on top of Tiles' i18n concept to offer localized Web > pages based on an individual's language, country, personality and channel. > We make extensive use of Tiles Component definitions and inheritance in XML > files, and 667 out of the 668 definitions used by our app inherit from > another one. > > With the help of a Java profiler, we showed that 64% of the 79 MB of > memory was used by HashMap entries created by Tiles. This corresponds to > 50.5 MB of RAM. After close investigation, it turns out that the very useful > Tiles' component inheritance has been mis-implemented. > > Our application has only one definition that doesn't extend another one: > the root "pageDefinition", which contains common information such as > "pageCopyrightLink" for example. Other Component Definitions that extend > "pageDefinition", such as "disbursementCB", do not need to repeat this > information. When queried for the "pageCopyrightLink" value, the > "disbursementCB" component will delegate the processing to its parent > component, in this case "pageDefinition". > > Unfortunately, this handy conceptual delegation is actually not > implemented in a similar way in the Tiles source code. > > In our example, when the "disbursementCB" component is instantiated in > memory, the Tiles source code does not pass it a reference to the parent > "pageDefiniton" component. Instead, Tiles forces the new "disbursementCB" > component to make a deep copy of all values defined in its parent(s). This > means that, ultimately, our application ends up with 668 copies of the > "pageCopyrightLink" value in memory, instead of one. > > After modification of the Tiles source code so that true delegation is > actually happening in memory at runtime, new heap allocation statistics > showed that the problem with excessive usage of HashMap$Entry has been > completely solved. The most in-use object in the JVM is now of the type > "[C", a common and normal trend in typical Java applications. > > The total amount of memory was also down to 28 MB. This is a pleasant 51 > MB gain over the previous result. > > -- > > Finally, without being too demanding, we would appreciate if a patched > version of Tiles could be made available for for both the upcoming Struts > 1.1 release and the current stabe Strust 1.0.2 one. > > > Best Regards, > > > Christophe Warland > > > -------------------------------------------------------------------------- -- > -- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ---------------------------------------------------------------------------- ---- > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
