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

[Steve Ebersole]

We do.

On 10/02/2012 03:31 PM, Andrig Miller wrote:
>
>
> ----- Original Message -----
>> From: "Steve Ebersole" <steve at hibernate.org>
>> To: "Sanne Grinovero" <sanne at hibernate.org>
>> Cc: "John O'Hara" <johara at redhat.com>, spederse at redhat.com, "Andrig Miller" <anmiller at redhat.com>, "Jeremy Whiting"
>> <jwhiting at redhat.com>, "Will Reichert" <wreicher at redhat.com>, "Hibernate" <hibernate-dev at lists.jboss.org>
>> Sent: Tuesday, October 2, 2012 1:43:51 PM
>> Subject: Re: [hibernate-dev] Runtime efficiency: sharing some profiling output
>>
>> 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.
>>
>
> Could you set the concurrency level to one?
>
> Andy
>
>>
>>
>> --
>> steve at hibernate.org
>> http://hibernate.org
>>

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