FYI my memory usage branch can be found here: https://github.com/stuartwdouglas/core/tree/memoryUsage
With the last lot of changes to WeldClassImpl memory usage is down by about 60Mb ( ~30%) for the 5000 class benchmark. The fields that I have removed are only used at startup of during de-serialisation. The effect on startup time is not noticeable, and I think that cost of de serialisation will be significantly higher than any overhead imposed by these changes, although I have not benchmarked this yet. There is still plenty more that can be done here, I think reducing the memory usage by 50% should be easily achievable. Stuart On 10/11/2010, at 9:57 PM, David Allen wrote: > Stuart, > > Excellent! There shouldn't be too many hash maps left in WeldClassImpl. > Most of these have already been replaced with array set implementations; the > ones left are a bit more complicated to replace due to use cases. > > Pete also wanted to redo the reflection data that we maintain and cache. It > should be possible to release most of this cached data after bootstrapping > the app. As it is now, everything is kept in memory permanently with the app > which really isn't necessary. > > I'm supposed to be working on this, but I don't think I'll have much time > till January 2011 to really do much. Keep us posted and I'll try to take a > look on weekends or whenever I have a little time. > > Thanks, > > David > > On Wed, Nov 10, 2010 at 11:12 AM, Stuart Douglas <[email protected]> > wrote: > Clearing the resolvers after startup saves about 42Mb in the 5000 bean case > (~20% of the memory attributable to weld, and ~10% of total memory usage). > > Stuart > > > On Wed, Nov 10, 2010 at 8:12 PM, Stuart Douglas <[email protected]> > wrote: > > I just ran some very quick and dirty profiling with the latest Jbossas and > the results are as follows: > > > Beans Startup Time Startup (WELDX) Memory Usage Mem Usage(no beans.xml) > No Deployment 17 135 > 20 20 22 149 > 500 24 26 178 > 2000 35 43 265 > 5000 87 104 440 210 > > > So jboss uses 135Mb normally, and 210Mb when a war with 5000 classes is > deployed that does not have beans.xml. When you add weld to the mix the > memory usage jumps by 230Mb to 440Mb. > > According to yjp WeldClassImpl (and it's retained WeldMethod/Field etc) is > responsible for 120Mb of this. Other major culprits seem to be > TypeSafeObserverResolver at 24Mb (as it is caching > ProcessAnnotatedType<Bean*> * 5000) and TypeSafeDecoratorResolver at 13Mb. > Not much else stands out. > > The beans used where quite simple (1 injection point, 7 fields, 6 methods), > no normal scoped beans, no interceptors, not decorators. Weldx does have a > notable effect on startup time, which I will also investigate. > > I don't think it will be to hard to significantly reduce this. Reducing the > number of HashMap's in WeldClassImpl (and replacing some with > ImmutableArraySet) should give a significant gain, and clearing the > TypeSafeObserverResolver and TypeSafeDecoratorResolver after startup should > also save around 40Mb. I'll try and do some work this week and see how much I > can get this down. > > Stuart > > On 10/11/2010, at 8:48 AM, Pete Muir wrote: > >> I'm about to post a blog about this. >> >> On 9 Nov 2010, at 21:43, Lincoln Baxter, III wrote: >> >>> Are these points valid? >>> >>> If so, are we aware of them? Just trying to raise awareness to what people >>> are saying out in the world. I have noticed a relatively high memory >>> footprint in Seam Forge, using Weld SE. >>> >>> http://www.dzone.com/links/r/cdi_a_major_risk_factor_in_java_ee_6.html >>> >>> Is there anything we can address here and attempt to demystify this blog? >>> >>> -- >>> Lincoln Baxter, III >>> http://ocpsoft.com >>> http://scrumshark.com >>> "Keep it Simple" >>> _______________________________________________ >>> weld-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> _______________________________________________ >> weld-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/weld-dev > > > > _______________________________________________ > weld-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/weld-dev >
_______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
