Cache char[] instances #178
Conversation
… to use a thread-local, cached char[] instance when serializing types that need one rather than allocating an instance each time it's needed.
|
This has been suggested in the past, but I'm hesistant about adding a dynamically sized cache. Jil does allocate some stuff as it's used that isn't reclaimed (because it hangs off of types typically as a static), but once the first hit is paid for the overhead is more or less constant for that type. A dynamically sized cache to conceivably eat up quite a lot of memory if large object graphs are in play, and that could be pretty bad depending on the app. Offhand, at least the public api on Stack Overflow (a Jil consumer) would be at risk of encountering serious issues. |
|
Kevin, did you look at the code in the PR I submitted? The cache is not dynamically-sized, it's just a fixed-length char[] stored in a thread-static field. The cached array is created on-demand so it's only created if it's actually used, and the number of buffers created has an upper bound which is the number of threads in the process. |
|
@jack-pappas I thought I had, but clearly I didn't (or I confused myself) - will re-evaluate, my apologies. |
I've made some small modifications to cache
char[]instances in a thread-local variable instead of re-allocating them each time one is needed (e.g., to serialize aDateTimeto ISO8601 format). Running the "quick graph" mode of the benchmark tool didn't show any real difference (better or worse), but it seems better to have fewer allocations/GCs if possible to avoid impacting other code in the process.