Note: also considered (but ultimately rejected) idea of a separate
`*thaw-mapfn*` opt that operates directly on every `thaw-from-in!`
result.
This (transducer) approach is more flexible, and covers the most
common use cases just fine. Having both seems excessive.
This change affects small: strings, vectors, sets, and maps so that
they use *unsigned* element counts.
Before: counts in [0, 127] use 1 byte
After: counts in [0, 255] use 1 byte
I.e. doubles the range of counts that can be stored in 1 byte.
This changes saves:
- 1 byte per count in [128, 255]
Is this advantage worth the extra complexity? Probably no in isolation,
but this is a reasonable opportunity to lay the groundwork for unsigned
element counts for future types.
Before:
Longs in [ -128, 127] use 1 byte
Longs in [-32768, 32767] use 2 bytes
etc.
After:
Longs in [ -255, 255] use 1 byte
Longs in [-65535, 65535] use 2 bytes
etc.
I.e. doubles the range of longs that can be stored by 1, 2, and 4 bytes.
This changes saves:
- 1 byte per long in [ 128, 255], or [ -129, -255]
- 2 bytes per long in [32768, 65535], or [-32769, -65535]
- 4 bytes per long ...
Is this advantage worth the extra complexity? Probably yes, given how
common longs (and colls of longs) are in Clojure.
This reverts commit f1af0cae674f7dea29d460c5b630a58c59c7dcab.
Motivation for revert:
At least 1 user has reported depending on the current `cache`
feature, and implementing it manually (i.e. outside of Nippy) can
be non-trivial.
Rather than risk breaking folks, I'll take some more time to
consider alternatives. There's no urgency on this.
This commit is BREAKING for those still actively using `nippy/cache`.
Data previously frozen using `nippy/cache` can still be thawed, though
support for thawing may also be removed in a future Nippy version.
Motivation for removal:
This cache feature (marked as experimental) was always a bit dubious.
The use cases were very limited, and the complexity quite significant.
I don't believe that the feature has ever had much (any?) public
adoption, so I'm removing it here.
PLEASE LET ME KNOW if this removal negatively impacts you.
Not strictly necessary, but probably not a bad idea to encourage folks
to at least get on v3.x since it does contain relevant performance
improvements.
Shouldn't be any reason preventing folks from using the latest version
of Encore unless they're on a really ancient version of Clojure
(< v1.7 released 2015).
