[hibernate-dev] Runtime efficiency: sharing some profiling output

[Steve Ebersole]

See comments inline...

On Tue 02 Oct 2012 01:13:39 PM CDT, Sanne Grinovero wrote:

> # IdentityMap
> Some performance is lost in the well known
> org.hibernate.engine.internal.StatefulPersistenceContext; especially
> the IdentityMap and it's need for System.identityHashCode is
> demanding.
> New in this run is the surprising cost of #clear() : 0,5% CPU.. not
> alarming, but it looks like I can blame again IdentityMap,
> specifically: concurrentEntries.

We have discussed the IdentityMap concerns quite a few times in past 
few weeks.  For background, this is mainly a problem with 
PersistenceContext and the fact that it holds a few identity-based 
(rather than equality-based) Maps to track various states related to 
entities and collections.  The bottleneck here is actually 
System#identityHashCode we have since found, which is a native call.  
Same thing for Object#hashCode, even if we could consistently rely on 
it.

This can be at least partially alleviated by moving to bytecode 
enhancement and offloading the state maintained in PersistenceContext 
to the enhanced entity classes.  Of course this is a non-simple change 
and we really do not know what other performance problems this might 
then cause.


> # DefaultEntityAliases.intern
> Why are we interning this?
> org.hibernate.loader.DefaultEntityAliases.intern(String[])
> If they are constants, I guess they could be reused rather than
> re-computed all the time.. in fact, see next point:
>
> # Aliases and other string generations
> It seems Hibernate ORM is generating property aliases and other little
> Strings all the time; this test isn't using any HQL, just direct
> loading of entities via primary keys or by following relations from
> other managed entities.

Isn't there a point where interning becomes wasteful?  Surely there 
must be.  What is that tipping point?


>   # org.hibernate.type.descriptor.sql.IntegerTypeDescriptor.getExtractor(JavaTypeDescriptor<X>)
>   Could we avoid returning a new instance on each demand ?

I am not sure how since in many cases we rely on being able to swap 
those incoming JavaTypeDescriptors.  Suggestions welcome.


>   # iterators on
> org.hibernate.internal.util.collections.ConcurrentReferenceHashMap.ConcurrentReferenceHashMap
>   Why are we having a concurrent Map in the StatefulPersistenceContext
> ? I thought this class wasn't meant to be shared among multiple
> threads?

As far as I know, the important piece is more the references.  AFAIK 
there are no non-concurrent reference map implementations available in 
any of our current dependencies.



--
steve at hibernate.org
http://hibernate.org