The problem with this is they have to go through the SPI at boot time (i.e. ProcessAnnotatedType and ProcessBean).
Stuart On Thu, Nov 11, 2010 at 11:09 AM, Shane Bryzak <[email protected]> wrote: > 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<[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 >>> >> >> > > _______________________________________________ > 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
