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

[Sanne Grinovero]

On 2 October 2012 20:43, Steve Ebersole <steve at hibernate.org> wrote:
> 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?

I'm not suggesting to use interning; what surprised me is that even
for standard load operations of an entity, Hibernate doesn't have a
"prepared" set of alias names; couldn't the metamodel for each entity
contain pre-computed alias names (or full SQL strings) to do the basic
CRUD operations on that entity?
Not being familiar with this code, I just found it odd that to load
the same entity type some million times it would recompute these alias
strings over and over.

>>   #
>> 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