[jbalunas.jbalunas.jboss.org]

Thanks Alex!

Please create a jira and attach your war and how you verify the slowdown with it.

Thank,

Jay

[asavitsky]

http://jira.jboss.com/jira/browse/JBSEAM-3024

[kahliburke.kahli.burke.wintermutesys.com]

As far as I can tell a big portion of this performance issue is related to the issue described in JBSEAM-2917. 

I tried backporting that fix into 2.0.2 with modifications because the calls are different in trunk.  That definitely increased performance considerably and my tests in the profiler showed that the bottleneck was removed.

[asavitsky]

Indeed, you're correct! Not sure why this issue didn't manifest itself in 2.0.1, but putting the patch did resolve the slowdown, bringing load times back to a manageable 5-6s.

Thanks a lot,

Alex

[shane.bryzak]

I don't understand how this patch can improve overall performance.  Where is Seam.getEjbDescriptor() actually called besides initialization time?

[cpopetz]

Shane Bryzak wrote on May 25, 2008 02:38:


I don't understand how this patch can improve overall performance.  Where is Seam.getEjbDescriptor() actually called besides initialization time?

It gets called on every component method invocation, for every non-null non-transient non-static non-injected field of the component (including inherited fields) whose type is neither a collection nor annotated with @Entity, via the following code path:

ManagedEntityIdentityInterceptor.aroundInvoke
   -> entityRefsToIds (every invocation)
   -> isRef  (for every qualifying field, in superclasses too)
   -> Seam.getEntityClass() 
   -> Seam.getEjbDescriptor() (for the class of the field as well as its superclasses)

Lets say you have on average three fields in your components, and each component has on average one non-trivial superclass.  Then getEjbDescriptor is called (6 fields * 2 classes per field) -> 12 times on every invocation of any method in any component.

This probably affects people with older code bases (which use hbms instead of @Entity for their model classes) a lot more.  Like me :)

As an aside, IMHO ManagedEntityIdentityInterceptor is the nemesis of all things performant.  This isn't the only place it's a hotspot.

[shane.bryzak]

Got it, thanks.  I was actually looking at the code in trunk, where Seam.getEntityClass() accesses EJB_DESCRIPTOR_CACHE directly, rather than calling getEjbDescriptor().  I've ported the fix back to the 2_0 branch anyway, which will be in the imminent SP1 release.  Hopefully that will fix the performance issues that people are experiencing.

[lich]

great job