You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looks like encoding methods in JsonStringEncoder were simplified in 2.10 to reduce likelihood of strange concurrency challenges (basically removing use of ThreadLocal). This was deemed not to be particularly performance/memory sensitive since methods are only used from one place, SerializedString.
One aspect that seems sub-optimal is the eager allocation of initial char[] / byte[] output buffer: 120 chars / 200 bytes.
Since the values most likely encoded are names, which tend to be a bit shorter, this is bit wasteful.
It may or may not be an actual concern for Jackson but seems like something easy enough to fix.
A simple change would be to shrink default lengths to something like 30 / 60 (for example), but given that we have information on actual input String length, we should be able to do better and calculate buffer that is likely sufficient.
The text was updated successfully, but these errors were encountered:
Improved this properly for 2.13; 2.11/2.12 just get lower starting lengths (which should likely reduce overhead anyway), if new patch releases are made.
Looks like encoding methods in
JsonStringEncoder
were simplified in 2.10 to reduce likelihood of strange concurrency challenges (basically removing use ofThreadLocal
). This was deemed not to be particularly performance/memory sensitive since methods are only used from one place,SerializedString
.One aspect that seems sub-optimal is the eager allocation of initial
char[]
/byte[]
output buffer: 120 chars / 200 bytes.Since the values most likely encoded are names, which tend to be a bit shorter, this is bit wasteful.
It may or may not be an actual concern for Jackson but seems like something easy enough to fix.
A simple change would be to shrink default lengths to something like 30 / 60 (for example), but given that we have information on actual input
String
length, we should be able to do better and calculate buffer that is likely sufficient.The text was updated successfully, but these errors were encountered: