Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v3/v5: memoize clones of digested namespaces #18

Open
danlentz opened this issue Feb 18, 2015 · 3 comments
Open

v3/v5: memoize clones of digested namespaces #18

danlentz opened this issue Feb 18, 2015 · 3 comments

Comments

@danlentz
Copy link
Owner

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

@arrdem
Copy link

arrdem commented Feb 18, 2015

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
Copy link
Owner Author

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
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants