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

[Luis Barreiro]

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 <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

-- 
Luis Barreiro
JBoss^® by Red Hat