Thanks for the prompt reply Tatu! [My comments are inline.]
On Sunday, December 29, 2019 at 12:31:42 AM UTC+1, Tatu Saloranta wrote: > > On Fri, Dec 27, 2019 at 3:29 AM Volkan Yazıcı <[email protected] > <javascript:>> wrote: > > 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. > I had bumped into #514 <https://github.com/FasterXML/jackson-core/issues/514>. Here #577 proposes incorporating jsoniter enhancements, while #514 proposes using ryu <https://github.com/ulfjack/ryu>, which is the library behind jsoniter, AFAIU. > > #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) > This did not really work for me. But right now I cannot recall why. I will give this another try and will let you know. > 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 :) > Yep, my conclusion is JMH-driven. > 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. > Created #587 <https://github.com/FasterXML/jackson-core/issues/587>. -- 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/d6d783ca-a09a-4b40-ab0d-030edd61bbcd%40googlegroups.com.
