On Fri, Dec 27, 2019 at 3:29 AM Volkan Yazıcı <[email protected]> wrote:
>
> Hello,
>
> Is there a faster way to encode floating-point numbers in JsonGenerator?

Not currently. I think there is an issue filed to support faster
encoding... this one:

https://github.com/FasterXML/jackson-core/issues/577

so if you or anyone else was interested in working on that -- esp.
since there is some prior art to use (Jsoniter author offered his help
which is very nice) -- that would be very useful.

But as to other specific alternatives:

> #writeNumber(double) falls back to Double.toString(), which is known to be 
> not very efficient. In my particular case, I want to encode a j.u.Instant. 
> Instant is, in principle, composed of epoch seconds (integral part) and nanos 
> (fractional part). Hence, I can actually easily do #writeNumber("" + 
> epochSeconds + '.' + epochSecondsNanos). Though, this has one caveat: String 
> allocation. Given I have two long's denoting the integral and fractional 
> parts of a floating-point number, is it possible to output this via 
> JsonGenerator without extra allocation?

I guess that if you are only focusing on JSON output (and not other
formats), you could probably use sequence of:

    writeRawValue(firstPart);
    writeRaw(secondAndOthers)

to get output that would not require String allocation on caller side
(and buffering does not construct Strings) and should add proper
separators. `writeRawValue()`, specifically, ensures that preceding
separator(s) / indentation is added, whereas `writeRaw()` explicitly
does nothing.

Whether doing this is worth the hassle is an open question, I think;
you may want to write benchmark to investigate performance benefits.
My guess is that String concat/allocation won't be significant
overhead in this case -- but I have been wrong before so measurements
trump educated guesses :)

One more thing: although it wouldn't help you at this point, addition
of something like

    writeNumber(char[] buffer, int offset, int length);

for 2.11 would also allow caller to reuse encoding buffer. If that
seems useful, please file an issue for `jackson-core`: addition would
be trivial and could go in 2.11.

I hope this helps!

-+ Tatu +-

-- 
You received this message because you are subscribed to the Google Groups 
"jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jackson-user/CAL4a10hP0MJ%3Dc5QhgROWB41vzvS77TghGe-GSX3pyPy_QGrTdg%40mail.gmail.com.

Reply via email to