> You want us to delay enhancement until after the persisters are built.
No, I mean to let enhancement define the attribute ordering and initialize persisters with that previously defined order. > What I suggest longer term is a slight variation... Yes, that sounds nice. 2015-11-12 16:07 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > But see that is exactly the problem. That cannot work. You want us to > delay enhancement until after the persisters are built. But building the > persisters requires access to the Class. But by that time since we have the > Class reference we can no longer enhance it. It's a chicken-egg problem. > > What I suggest longer term is a slight variation, where we drive the > "indexing" based on the mapping model. Actually that also will not work as > the code is today. Really what I'd like to do is to leverage the > jandex-binding work. Specifically there we have a Jandex-driven pre-parsing > of the domain model (including XML augmentation). That model would be > perfect for this. > > On Thu, Nov 12, 2015 at 9:00 AM Gunnar Morling <gun...@hibernate.org> wrote: >> >> 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