32 ms·
is there even a good reason for this to be cached. this almost like a memory leak. if someone wants to cache the result of toString they should be doing it in c
by benmmurphy 9y ago
is there even a good reason for this to be cached. this almost like a memory leak. if someone wants to cache the result of toString they should be doing it in client code. this shouldn't be something that is forced on everyone.
- Cthulhu_ 9y agoAnd yet, it's an interface, as a user you don't notice this performance improvement at all - it returns a string version of an (immutable) data structure, how it does that and whether it caches it is not something that the client can control, and thus not something they should care about too much. What they should and will care about is the performance of BigDecimal.toString(), and if it's cached then the 2nd and onward calls will be very fast. Mind you, I'm sure there's a lot of similar optimizations in a lot of toString() implementations; a generic implementation that is threadsafe would be preferable to a roll-your-own-caching.
- wruza 9y agoFyi, there are well-known safe approaches like memoize() to do that instead of roll-your-own. Selecting hidden cache field for every damn value seems like the legacy architectural error. Also, on some platforms not caching this at all would be better than caching under atomic primitive.