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(a)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(a)gmail.com> wrote:
>
> From: Stuart Douglas<stuart.w.douglas(a)gmail.com>
> Subject: Re: [weld-dev] A significantly negative article on Weld
> To: "Pete Muir"<pmuir(a)bleepbleep.org.uk>
> Cc: "Samuel Mendenhall"<samuel.mendenhall(a)gmail.com>, "Weld Dev
List"<weld-dev(a)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(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
>