We do this because this is what the spec says we have to do :-) Stuart
On Thu, Nov 11, 2010 at 7:46 AM, Mark Struberg <[email protected]> wrote: > Sorry to drop in here, but I think there might be a conceptional problem. Why > do we pickup each and every class as @Dependent? In most cases this is either > unnecessary or even leads to AmbiguousResolutionExceptions. > > I'd strongly favour to drop this and instead only pickup a bean as managed if > it has a scope annotation or a few other very limited cases. This would also > highly increase startup time imo... > > LieGrue, > strub > > > --- On Wed, 11/10/10, Stuart Douglas <[email protected]> wrote: > > From: Stuart Douglas <[email protected]> > Subject: Re: [weld-dev] A significantly negative article on Weld > To: "Pete Muir" <[email protected]> > Cc: "Samuel Mendenhall" <[email protected]>, "Weld Dev List" > <[email protected]> > Date: Wednesday, November 10, 2010, 9:12 AM > > > 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 > > > -----Inline Attachment Follows----- > > _______________________________________________ > 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
