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.
--
steve(a)hibernate.org
http://hibernate.org