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. Does jackson avoid creating intermediate strings when deserializing enum values? > 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? 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.
