Closed cowtowncoder closed 11 months ago
Working on PR for this one (#402) I did a bit of local performance testing and had hard time finding actual speed up even for small documents (about 300 bytes). Looking at implementations, generator-side in particular seems less than useful, only recycling default-sized (64 entries) buffers.
So I think I'll try alternate PR in which recycling is completely removed instead.
Did instead #403, closing this issue.
Now that
jackson-core
added pluggability of recycler pools (see https://github.com/FasterXML/jackson-core/issues/1089 ), and also provides a set of reusable implementations (see https://github.com/FasterXML/jackson-core/pull/1064) we can tackle Smile-specific additional recycling: it also needs to allow re-configuring esp. to work with Project Loom whereThreadLocal
based pooling really does not work well. This is likely to also help with Android usage, whereSoftRefernence
s (used by default Smile recycler, in addition toThreadLocal
) does not work as well as vanilla J2SE JDKs.So let's try to get this done for 2.16.
Class to change is
SmileBufferRecycler
. For 2.16 we should still default to traditional recycler, but for 2.17+ should probably change the default. This allows for early adopters to switch over sooner, while we get feedback on how pooling works, best default to use.