We do. On 10/02/2012 03:31 PM, Andrig Miller wrote: > > > ----- Original Message ----- >> From: "Steve Ebersole" <st...@hibernate.org> >> To: "Sanne Grinovero" <sa...@hibernate.org> >> Cc: "John O'Hara" <joh...@redhat.com>, spede...@redhat.com, "Andrig Miller" >> <anmil...@redhat.com>, "Jeremy Whiting" >> <jwhit...@redhat.com>, "Will Reichert" <wreic...@redhat.com>, "Hibernate" >> <hibernate-dev@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 > >> >> >> -- >> st...@hibernate.org >> http://hibernate.org >>
-- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
