On Mon, Mar 27, 2023 at 11:11 PM Viktor Szathmáry <phrak...@gmail.com> wrote: > > Hi, > > > > On Mar 28, 2023, at 02:01, Tatu Saloranta <t...@fasterxml.com> wrote: > > > > On Mon, Mar 27, 2023 at 2:15 PM Viktor Szathmáry <phrak...@gmail.com> wrote: > > > > Right, it depends on what are important optimizations: if it is > > important to avoid intermediate String generation then things get more > > complicated. If not, then it could be handled by deserializer itself > > (accessing String, canonicalizing as second step). > > Indeed, the objective here is two-fold: > 1) pull strings from a pool (improving locality/hashcode/equals down the line) > 2) avoid string (or other intermediate buffer) allocation altogether > (reducing GC pressure) > > Achieving #1 is easy with a custom deserializer, I’m more interested in #2.
Ok, yes, that makes sense. > Does jackson avoid creating intermediate strings when deserializing enum > values? Not currently, no (with JSON). But as I said, decoding from bytes to chars itself does not require allocations, yet. So `parser.getTextCharacters()` for example typically avoids allocations (except for buffer boundaries, long strings etc). > > But there are different approaches even without String allocation: > > decoding from input can be done (and generally is) into intermediate > > `char[]` buffer, so callback could be used to get access to that > > buffer (and offset, length), to avoid allocation but without having to > > deal with UTF-8 (etc) decoding. > > For that there'd probably need to be addition of something like > > > > String getText(DecodingCallback cb); > > Assuming my underlying buffers are byte arrays, is there a way to access that > from a custom deserializer (without copying) and apply a > ByteQuadsCanonicalizer? No. It is not easy to link, either, as it is rather specialized decoding. For text value handling I'd probably start with something else than ByteQuadsCanonicalizer / CharToNamesCanonicalizer. Although latter could probably work better. Jackson 3.0 has yet another mechanism geared at name canonicalization, in which BeanDeserializer sort of owns lookup table. That approach would probably work better for Enums etc. But, then again, Jackson 3.0 is still not about to be released. (and this particular technique difficult to backport; you can check out `JsonParser` methods in `master` branch, Class/interface is "PropertyNameMatcher". It is effectively a callback and allows caller to pass a Dictionary. That approach might generalize to String values, not just property names. -+ Tatu +- > > Thanks, > Viktor > > -- > 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 jackson-user+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-user/3A8E6205-6C7F-43EC-BF36-9A361C2C5656%40gmail.com. -- 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 jackson-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/CAL4a10hFiLQ9oLWzFJ-WTJ89DAeU%3Dad1M6mbi0tpYACaQsDKpg%40mail.gmail.com.
