It would be a one-time effort during persister initialisation; At that time a look-up would happen in order to seed persisters with attributes in the order as determined by the enhancer. Then at runtime, upon getter/setter invocation, the index values passed from the enhanced code would be used as is for array index access in persisters.
2015-11-12 15:30 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > 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 <st...@hibernate.org> 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 <gun...@hibernate.org> >> 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 <st...@hibernate.org>: >>> > 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@lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev