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
p
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 w
> 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+0
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.
W
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
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, nast
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
>
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
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
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_na
10 matches
Mail list logo
