3:43 p.m.
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"
3:48 p.m.
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
3:12 a.m.
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
4:12 a.m.
Clearing the resolvers after startup saves about 42Mb in the 5000 bean case
(~20% of the memory attributable to weld, and ~10% of total memory usage).
Stuart
On Wed, Nov 10, 2010 at 8:12 PM, Stuart Douglas
<stuart.w.douglas(a)gmail.com>wrote:
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
5:35 a.m.
On 10 Nov 2010, at 10:12, Stuart Douglas wrote:
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.
This is where David has concentrated his work so far. The next step as we've discussed
before is to switch these over to use builders or factories to create the instances which
should allow us a much clearer view of what is going on.
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.
Good point, we don't need to hold this at all after boot.
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.
Also, I know we hold too much around after bootstrap -- afaict we hold onto BeanDeployer
instances when these should be got rid of. This directly has minimal impact, but it may
allow for better GC later on as references to some WeldClass instances may at this point
be removed. Worth checking.
5138
days inactive
5139
days old
4 comments
3 participants
participants (3)
-
Lincoln Baxter, III -
Pete Muir -
Stuart Douglas