Re: [weld-dev] A significantly negative article on Weld
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