Re: [hibernate-dev] Bytecode interception and attribute name versus attribute index
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 :
> 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
Re: [hibernate-dev] Bytecode interception and attribute name versus attribute index
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 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 :
> > 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
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 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
> 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 :
>> > 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
Re: [hibernate-dev] Bytecode interception and attribute name versus attribute index
On 11/12/2015 08:36 AM, Gunnar Morling 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.
I was having the same line of though, to expose the attribute order.
Going that route, I don't think we do have to make it consistent with
the persisters order ... making it more independent, and therefore more
robust.
What we would need is to understand 'enhancedIndexes' in the integration
points. I'll try to hack something in the next couple of days.
> --Gunnar
>
>
> 2015-11-11 21:37 GMT+01:00 Steve Ebersole :
>> 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
--
Luis Barreiro
JBoss^® by Red Hat
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Bytecode interception and attribute name versus attribute index
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 :
> 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 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
>> 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 :
>>> > 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?
>>> > ___
>>> > hibern
Re: [hibernate-dev] Bytecode interception and attribute name versus attribute index
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 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 :
> > 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
> 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
> >> 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 :
> >>> > 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 mor
Re: [hibernate-dev] Bytecode interception and attribute name versus attribute index
> 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 :
> 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 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 :
>> > 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
>> > 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
>> >> 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 :
>> >>> > 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 t
Re: [hibernate-dev] (no subject)
https://hibernate.atlassian.net/browse/HHH-10280 https://hibernate.atlassian.net/browse/HHH-10281 On Wed, Nov 11, 2015 at 12:15 PM andrea boriero wrote: > no objections > > On 11 November 2015 at 17:55, Steve Ebersole wrote: > >> I'd like to more formally deprecate the legacy bytecode enhancement >> starting in 5.0.4 and remove it in 5.1. >> >> The new code is superior and already feature compatible back to 5.0 Final. >> >> Any objections? >> ___ >> 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
Re: [hibernate-dev] (no subject)
+1 On 12 November 2015 at 16:39, Steve Ebersole wrote: > https://hibernate.atlassian.net/browse/HHH-10280 > https://hibernate.atlassian.net/browse/HHH-10281 > > On Wed, Nov 11, 2015 at 12:15 PM andrea boriero wrote: > >> no objections >> >> On 11 November 2015 at 17:55, Steve Ebersole wrote: >> >>> I'd like to more formally deprecate the legacy bytecode enhancement >>> starting in 5.0.4 and remove it in 5.1. >>> >>> The new code is superior and already feature compatible back to 5.0 Final. >>> >>> Any objections? >>> ___ >>> 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 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Bytecode interception and attribute name versus attribute index
Sounds like a very interesting patch, I agree with you that there's
much potential.
Although Steve from your description it seems like you don't think it can work?
I would expect something among the lines of what Gunnar described to
be feasible: to let the persisters figure out the right numbers when
they are created (once only). But I am not familiar enough with this
code area to get in the details.
About the method you mentioned " $$_hibernate_read_name()" : who
invokes that, and when is the code which invokes that method
generated?
I'm assuming that would be part of the persister, so it means
persister implementations are defined at runtime via bytecode
manipulation?
On 12 November 2015 at 15:18, Gunnar Morling wrote:
>> 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 :
>> 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 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 :
>>> > 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
>>> > 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
>>> >> 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 :
>>> >>> > 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 );
>>> >
Re: [hibernate-dev] Bytecode interception and attribute name versus attribute index
On Thu, Nov 12, 2015 at 2:44 PM Sanne Grinovero wrote:
> Sounds like a very interesting patch, I agree with you that there's
> much potential.
> Although Steve from your description it seems like you don't think it can
> work?
>
Not sure I follow. You agree with the potential of the idea I am
proposing, but then point out how I don't think it will work. I am
confused :)
I guess I think there are different shades of "it works". I mean heck "it
works" as is already. I think it works *best* if there is no need to
"translate" from one canonical form to another. In other words, if
persisters and bytecode enhancements and dirty tracking all understood the
same attribute indexes I think that is by far the optimal situation
performance-wise.
I would expect something among the lines of what Gunnar described to
> be feasible: to let the persisters figure out the right numbers when
> they are created (once only). But I am not familiar enough with this
> code area to get in the details.
>
But that's not what Gunnar proposed. Its the same thing I asked him to
clarify. He proposes the "other way"; have the enhancer define the order
and the persisters pick it up from the enhancer. Could that work? I
guess. Really I have no idea, so many unknowns there.
About the method you mentioned " $$_hibernate_read_name()" : who
> invokes that, and when is the code which invokes that method
> generated?
> I'm assuming that would be part of the persister, so it means
> persister implementations are defined at runtime via bytecode
> manipulation?
>
That is a method generated by the enhancer. Generally speaking it builds a
reader/writer method pair for each "enhanceable" field. For readers, the
name of the method follows the pattern "$$_hibernate_read_{fieldName}().
The callers of this method are all done via enhancement as well.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] (no subject)
Hey, How would migration for a user look like? Do they need to configure a different Ant/Gradle/Maven task? Would 5.1 (assuming the old enhancer has been removed) be able to work with entities enhanced by the old one, or would a re-build of the app be required? Would they see a deprecation at all in their IDE (do they interact with any classes related to enhancement directly at all)? Just trying to figure how painless migration for users to the new enhancer would be and whether 5.1 or possibly 6 would be the best time to remove the old approach. Thanks, --Gunnar 2015-11-12 17:46 GMT+01:00 Sanne Grinovero : > +1 > > On 12 November 2015 at 16:39, Steve Ebersole wrote: >> https://hibernate.atlassian.net/browse/HHH-10280 >> https://hibernate.atlassian.net/browse/HHH-10281 >> >> On Wed, Nov 11, 2015 at 12:15 PM andrea boriero wrote: >> >>> no objections >>> >>> On 11 November 2015 at 17:55, Steve Ebersole wrote: >>> I'd like to more formally deprecate the legacy bytecode enhancement starting in 5.0.4 and remove it in 5.1. The new code is superior and already feature compatible back to 5.0 Final. Any objections? ___ 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 > ___ > 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
