I'm not sure there's much we can do about this. As you stated, when you disable implicit cdi you get the same results as before. With implicit cdi enabled cdi is getting involved with the ejbs and so additional processing is happening. If cdi is not required then it should be turned off for maximum performance.

I don't think "work as intended" is an accurate description – I don't think the intention of enabling CDI by default is to introduce a 30% performance regression in EJB operations.

We need to look into and optimize the Weld implementation here. If we conclude that it cannot be improved on, then we can figure out next steps. But I suspect, given the size of the penalty, that there is some optimizing we can do. I'll get PSR staff to do some initial analysis (but also, can we check with the Weld implementors and see if they are aware of this, as they were already aware of the memory leak)?

Enabling CDI causes CDI to get involved in all EJB requests so if there's a lot of EJB "action" happening then there's going to be a performance hit when CDI is involved. I agree 30% seems drastic!

It's entirely possible that Weld can improve the implementation and I'll be glad to open a Weld Jira. It would be very helpful if I could provide some more information as well as an application that when run emphasizes the performance hit...Can the PSR staff provide that info?

(btw, The weld guys were not aware of the memory leak until we pointed it out )