On 2 October 2012 20:43, Steve Ebersole <st...@hibernate.org> wrote: > 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?
I'm not suggesting to use interning; what surprised me is that even for standard load operations of an entity, Hibernate doesn't have a "prepared" set of alias names; couldn't the metamodel for each entity contain pre-computed alias names (or full SQL strings) to do the basic CRUD operations on that entity? Not being familiar with this code, I just found it odd that to load the same entity type some million times it would recompute these alias strings over and over. >> # >> 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. > > > > -- > st...@hibernate.org > http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
