[weld-dev] A significantly negative article on Weld

[Marius Bogoevici]

Re: lazy handling of @Dependent beans - Not with the current contract - 
i.e. imagine this

@RequestScoped
public class Foo
{
     @Dependent Bar bar;
}

public class BarBar implements Bar
{
}

When the BeanManager is completely initialized, there must be 100%  
certainty that one and only one Bar implementation exists (this 
simplifies things by ignoring qualifiers). This can be achieved only by 
scanning all potential candidates upfront. That being said, there are 
means for reducing the scope of the scanning process (more granular bean 
deployments, custom scanner configuration - although this is Weld-specific).


On 10-11-10 7:09 PM, Shane Bryzak 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