v3/v5: memoize clones of digested namespaces

[danlentz]

this could save on v3/v5 hash but maybe some LRU cache might be more mindful of heap space

[arrdem]

core.cache is probably low enough churn that you can safely depend on it without causing issues for users, but unless this has clear performance gains even in the library "general use" case I wouldn't bother. Better to leave a whole in the API for users to pass in a cache instance and let them deal with what how and where.

[danlentz]

you may be right about focusing on the "general use" case. Im not sure -- its something that I will do some testing to see what kind of gains are feasible. It can't be good to just keep continually re-hashing the bytes of +namespace-url+ for example. As an alternative, the digest could be .cloned, just after the namespace .update, effectively interning the uuid namespace. But, I don't think the default behavior of any software should be to just continually and quietly continue to consume ever-more heap space, either, which is why I was thinking an LRU would be a really good choice -- there is a high likelihood it there will be relatively few namespaces used very often, i think. One could make a really big LRU -- just so long as we do not grow in an unbounded fashion I think a few megs of memory could possibly be a good trade here. @arrdem

[danlentz]

I've thought about it and I like your idea of leaving the option for the user to pass their own cache, if desired, rather than implementing within the library. Thanks, @arrdem that was a good suggestion.