make it allocation free on happy path

[wrandelshofer]

make it allocation free on happy path

[lemire]

(Note that I am not one of the authors of this library, just an observer.)

why allocate here??

Are you sure that there is heap allocation? What does escape analysis reveals?

lack of jmh tests is also troubling :(

Presumably, you are unsatisfied by DoubleParserJmhBenchmark.java?

[wrandelshofer]

Hi nevgeniev,

I did indeed implement a variant with a NaN that used some of the available bits in the NaN to encode that we need to go over the slow path. However this did not improve performance. It just made the code more complex.
Heap allocation occurs actually only in interpreted mode. The JIT inlines the called method and then removes the allocation. - In the use cases, in which I use FastDoubleParser, there is no point in optimizing interpreted mode.

Actually, there are jmh benchmarks in the test/jmh/java folder.

[nevgeniev]

@lemire ea could be very fragile actually... for it to work function allocating Double needs to be inlined first. And for this to happen certain hotspot threshold must not be hit. (max number of instructions already inlined and inlined stack depth) if those threshold were hit, hotspot will just stop inlining, so function allocating Double will become just a function call and actuall allocation would happen at least this is my understanding :).

     intx MaxInlineLevel                           = 9                                         {product} {default}
     intx MaxInlineSize                            = 35                                        {product} {default}
     intx MaxRecursiveInlineLevel                  = 1                                         {product} {default}

For example because of that effect Unsafe in latest jdk versions works slower for some libraries (stacks just became deeper as sun.misc.Unsafe became a facade rather than real Unsafe).. and to win performance back you need to adjust those thresholds

What I'm trying to say is that function relying on EA to be alloc free could be placed in context where hotspot won't be able to do inlining and eliminate allocation

tl;dr, personally I prefer to make code explicitly alloc free whenever is possible to avoid surprises

[nevgeniev]

@wrandelshofer yeah sorry I didn't notice, output in README was not from jmh this is why :(

[lemire]

@nevgeniev By very fragile... you mean that it is easy to cause heap allocation, even in the case where the function is called enough to be inlined.

This is very interesting. Can you provide me with such an example (an actual benchmark)... I'd love to take a look.

[wrandelshofer]

I have made the code now allocation free on the happy path in revision 343e4ae.