Re: [weld-dev] A significantly negative article on Weld

Couldn't we handle @Dependent beans in some kind of lazy manner? I.e. rather than picking them all up at deployment time pick them up when they're actually required. On 11/11/10 06:52, Clint Popetz wrote: > If you go that route, you lose the ability to inject instances of > third party classes without defining a @Produces method. That may be > preferable to the existing problems caused by default @Dependents, but > I wanted to point it out for clarity. > > -Clint > > On Wed, Nov 10, 2010 at 2:46 PM, Mark Struberg&lt;struberg(a)yahoo.de&gt; 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&lt;stuart.w.douglas(a)gmail.com&gt; wrote: >> >> From: Stuart Douglas&lt;stuart.w.douglas(a)gmail.com&gt; >> Subject: Re: [weld-dev] A significantly negative article on Weld >> To: "Pete Muir&quot;&lt;pmuir(a)bleepbleep.org.uk&gt; >> Cc: "Samuel Mendenhall&quot;&lt;samuel.mendenhall(a)gmail.com&gt;, "Weld Dev List&quot;&lt;weld-dev(a)lists.jboss.org&gt; >> 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 >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> -----Inline Attachment Follows----- >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> > _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev