[weld-dev] A significantly negative article on Weld

Pete Muir pmuir at bleepbleep.org.uk
Wed Nov 10 06:35:00 EST 2010


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.


More information about the weld-dev mailing list