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). <div><br></div><div>Stuart<br><br><div class="gmail_quote">On Wed, Nov 10, 2010 at 8:12 PM, Stuart Douglas <span dir="ltr"><<a href="mailto:stuart.w.douglas@gmail.com">stuart.w.douglas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><br></div><div>I just ran some very quick and dirty profiling with the latest Jbossas and the results are as follows:</div>
<div><br></div><div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse">
<table border="0" cellpadding="0" cellspacing="0" width="406" style="border-collapse:collapse">
<col width="84">
<col width="78">
<col width="94">
<col width="75" span="2">
<tbody><tr height="13">
<td height="13" width="84">Beans</td>
<td width="78">Startup Time</td>
<td width="94">Startup (WELDX)</td>
<td width="75">Memory Usage</td>
<td width="75">Mem Usage(no beans.xml)</td>
</tr>
<tr height="13">
<td height="13">No Deployment</td>
<td align="right">17</td>
<td></td>
<td></td>
<td align="right">135</td>
</tr>
<tr height="13">
<td height="13" align="right">20</td>
<td align="right">20</td>
<td align="right">22</td>
<td align="right">149</td>
<td></td>
</tr>
<tr height="13">
<td height="13" align="right">500</td>
<td align="right">24</td>
<td align="right">26</td>
<td align="right">178</td>
<td></td>
</tr>
<tr height="13">
<td height="13" align="right">2000</td>
<td align="right">35</td>
<td align="right">43</td>
<td align="right">265</td>
<td></td>
</tr>
<tr height="13">
<td height="13" align="right">5000</td>
<td align="right">87</td>
<td align="right">104</td>
<td align="right">440</td>
<td align="right">210</td>
</tr>
</tbody></table><br>
</span></div><div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse">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.</span></div>
<div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse">According to yjp WeldClassImpl (and it's retained WeldMethod/Field etc) is responsible for 120Mb of this. O</span><span style="border-collapse:collapse">ther major culprits seem to be TypeSafeObserverResolver at 24Mb (as it is caching ProcessAnnotatedType<Bean*> * 5000) and TypeSafeDecoratorResolver at 13Mb. Not much else stands out.</span></div>
<div><span style="border-collapse:collapse"><br></span></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><font color="#888888"><div>Stuart</div></font><div><div></div><div class="h5"><br><div><div>On 10/11/2010, at 8:48 AM, Pete Muir wrote:</div><br><blockquote type="cite"><div>I'm about to post a blog about this.<br>
<br>On 9 Nov 2010, at 21:43, Lincoln Baxter, III wrote:<br><br><blockquote type="cite">Are these points valid?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><a href="http://www.dzone.com/links/r/cdi_a_major_risk_factor_in_java_ee_6.html" target="_blank">http://www.dzone.com/links/r/cdi_a_major_risk_factor_in_java_ee_6.html</a><br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Is there anything we can address here and attempt to demystify this blog?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">
-- <br></blockquote><blockquote type="cite">Lincoln Baxter, III<br></blockquote><blockquote type="cite"><a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br></blockquote><blockquote type="cite"><a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
</blockquote><blockquote type="cite">"Keep it Simple"<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">weld-dev mailing list<br></blockquote>
<blockquote type="cite"><a href="mailto:weld-dev@lists.jboss.org" target="_blank">weld-dev@lists.jboss.org</a><br></blockquote><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>
</blockquote><br><br>_______________________________________________<br>weld-dev mailing list<br><a href="mailto:weld-dev@lists.jboss.org" target="_blank">weld-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div>