It's not easy to drop because it's part of the CDI spec I guess. But besides that I don't think it's a conceptual problem, it has a lot of advantages (injecting third party classes for example). In some cases (when startup times are important, e.g. on GAE) it would be nice to override this behavior though. The XML module in Seam 3 might be useful for declaring components, and all other components should be left untouched. A Java class would be even better for this (no XML parser overhead).
This is a big step back in the programming model, but makes Weld useable in situations that startup times and memory usage are very important. Paul Bakker ________________________________________ From: [email protected] [[email protected]] on behalf of Stuart Douglas [[email protected]] Sent: 10 November 2010 21:51 To: Mark Struberg Cc: Samuel Mendenhall; Pete Muir; Weld Dev List Subject: Re: [weld-dev] A significantly negative article on Weld 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 Op dit e-mail bericht is de disclaimer van Info Support van toepassing, zie http://www.infosupport.com/disclaimer _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
