Re: [hibernate-dev] Bytecode interception and attribute name versus attribute index

But I think that just redefines the same problem. Just that now instead of String->Integer we need some Integer->Integer resolution. Not sure that really gains us anything. On Thu, Nov 12, 2015 at 8:29 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > I have no estimate as to how much this would help. Many of the > improvements coming from the performance work have been of the sort that is > removing Map lookups; some of them across VERY small (and finite) sets of > Map keys. My concern here is that the Map look up occurs any time an > enhanced entity's getter or setter is called, which seems like a potentially > bigger performance impact. > > I'm going to table this for now until the jandex-binding work. But as > part of that work, I think it makes a ton of sense to make sure we develop a > strategy for consistent ordering of processing attributes. > > On Thu, Nov 12, 2015 at 2:36 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: >> >> Is there any estimate what would be gained perf-wise by doing this >> optimization? >> >> > First, this obviously is more fragile than relying on names; if the >> > order >> > changes but the bytecode is not re-enhanced, that could lead to very >> > subtle, nasty problems. >> >> Agreed, but to me it seems acceptable with such optimization having to >> be explicitly enabled and the docs of that setting describing this >> matter clearly. >> >> > The other issue is that this requires us to be able to consistently be >> > able >> > to order the attributes. >> >> Maybe the enhancer could enhance entities with a (static) method >> returning the attribute order it works with, or maybe some separate >> contract for making this order available. Then at runtime this order >> could be fed to persisters et al. for enhanced entities. >> >> Not sure whether it's doable or how complex it'd be, just throwing out >> the idea. >> >> --Gunnar >> >> >> 2015-11-11 21:37 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> > As I work on HHH-10267, a thought that keeps coming up in my head is >> > that >> > it would be great to avoid Map lookups in the enhancement and >> > interception >> > code. >> > >> > As an example of what I mean, consider the reader for a String field >> > named >> > `name` which roughly looks like: >> > >> > public String $$_hibernate_read_name() { >> > return (String) $$_hibernate_getInterceptor().readObject( this, >> > "name", >> > this.name ); >> > } >> > >> > In the interception code we need to resolve the attribute name ("name" >> > above) to the pertinent information from the persister,etc. Typically >> > this >> > is a Map lookup; sometimes it is a done by iterating a String[] of the >> > attribute names. >> > >> > Ultimately the information is taken from persister and friends, which >> > means >> > that the information is generally already readily consumable via array >> > access once we have resolved the name to a proper index. Which got me >> > thinking it would be great if we could encode the attribute index into >> > the >> > enhanced entity directly. Going back to the example about.. if we knew >> > that the "name" attribute was the 4th attribute (index=3) according to >> > the >> > entity persister we could leverage that information for better >> > performing >> > access to the attribute metadata in the enhanced code and interceptor: >> > >> > public String $$_hibernate_read_name() { >> > return (String) $$_hibernate_getInterceptor().readObject( this, 3, >> > this.name ); >> > } >> > >> > One gotcha - always has to be one devil right ;) Ok, 2 really... >> > >> > First, this obviously is more fragile than relying on names; if the >> > order >> > changes but the bytecode is not re-enhanced, that could lead to very >> > subtle, nasty problems. >> > >> > The other issue is that this requires us to be able to consistently be >> > able >> > to order the attributes. The Enhancer currently does not rely on the >> > built >> > metadata (org.hibernate.mapping) at all; it parses the entity >> > annotations >> > (completely annotation specific) on its own. Given the 2-phase break >> > down >> > in JPA bootstrapping, having Enhancer leverage the built metadata is >> > not >> > really going to be possible. Which is unfortunate, because doing so >> > would >> > be nice for other reasons (like supporting XML mappings for enhancement >> > as >> > well, etc). >> > >> > That's a lot of information, sorry about that :) >> > >> > But anyone have thoughts on that? >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev