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

[Gunnar Morling]

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 <steve at 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 <steve at 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 <gunnar at 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 <steve at 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 at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev