----- Original Message ----- > From: "Steve Ebersole" <steve(a)hibernate.org&gt; > To: "Sanne Grinovero" <sanne(a)hibernate.org&gt; > Cc: "John O'Hara" <johara(a)redhat.com&gt;, spederse(a)redhat.com, "Andrig Miller" <anmiller(a)redhat.com&gt;, "Jeremy Whiting" > <jwhiting(a)redhat.com&gt;, "Will Reichert" <wreicher(a)redhat.com&gt;, "Hibernate" <hibernate-dev(a)lists.jboss.org&gt; > 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(a)hibernate.org > http://hibernate.org >