Jacques,
I've tested your gist, and it seems that making class EH static helps a lot.
P.S. is it possible to avoid using ValueHolder classes?
like, for projection expression 'col_a + col_b', can we generate evaluator
classes simply as:
int eval(int index) {
return v1.accessor().get(index) + v2.accessor().get(index);
}
On Sun, Jul 28, 2013 at 9:13 AM, Jacques Nadeau <[email protected]> wrote:
> Hey Guys,
>
> I've been working on the right ValueHolder interfaces to avoid object
> allocation inside evaluation loops. It's easy when we're dealing with
> primitives but becomes more sticky when we're dealing with complex
> types like strings. There are two reasons I'm focused on this. The
> first is stack allocation. The second is scalar replacement. Stack
> allocation seems to work very well. However, scalar replacement seems
> slightly less reliable. I basically modeled three things we'll be
> doing:
>
> - Simple method (with alloc and without -- the current runtime
> evaluation already using this alloc approach)
> - Set (one using multiple parameters, the other using a single object
> that contained primitives)
> - Get (one using multiple methods, one using a passed in object that
> is then populated, the third creating an object inside the get method
> and returning that object)
>
> I had been hoping that the latest JRE was smart enough to do scalar
> replacements across a single method boundary. It looks like it works
> in most cases. Strangely, it doesn't seem to work correctly in the
> set(Object) method. That said, it doesn't seem like that big of a
> deal and just leads me to think that this should be done with multiple
> parameters on the ValueVector.Accessor's.
>
> Thoughts? I didn't spend a lot of time trying to make this a super
> accurate benchmark so let me know if you think there are holes in my
> benchmark?
>
> Jacques
>
> -----
>
> gist: https://gist.github.com/jacques-n/6096934
>
> ====With Escape Analysis enabled==== (-XX:+UnlockDiagnosticVMOptions
> -XX:MaxDirectMemorySize=4G)
> initial
> noalloc alloc ret alloc
> method 523 538
> set 593 788
> get 425 558 424
>
> warmed up
> noalloc alloc ret alloc
> method 336 337
> set 261 630
> get 406 379 402
>
> ====No Escape Analysis enabled==== (-XX:+UnlockDiagnosticVMOptions
> -XX:MaxDirectMemorySize=4G -XX:-DoEscapeAnalysis)
> initial
> noalloc alloc ret alloc
> method 532 3982
> set 619 1850
> get 429 1985 2096
>
> warmed up
> noalloc alloc ret alloc
> method 337 3546
> set 299 1817
> get 414 2133 2038
>
> Run leveraging Oracle JRE 7u25 on a 2.3ghz 2012 Macbook Pro.
>
