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