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

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