[weld-dev] A significantly negative article on Weld

[Stuart Douglas]

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 <sbryzak at redhat.com> 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<struberg at yahoo.de>  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<stuart.w.douglas at gmail.com>  wrote:
>>>
>>> From: Stuart Douglas<stuart.w.douglas at gmail.com>
>>> Subject: Re: [weld-dev] A significantly negative article on Weld
>>> To: "Pete Muir"<pmuir at bleepbleep.org.uk>
>>> Cc: "Samuel Mendenhall"<samuel.mendenhall at gmail.com>, "Weld Dev List"<weld-dev at lists.jboss.org>
>>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
>>>
>>> -----Inline Attachment Follows-----
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
>>
>>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>