-
-
Notifications
You must be signed in to change notification settings - Fork 489
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
Value of cached methods should not always be pickled #15692
Comments
comment:3
In #15149 it was proposed that caches should be 'opt-in and not opt-out' (#15149 comment:6). Imho most caches are not used for things that are horribly expensive to compute, they are just too expensive to be computed again all the time. Would somebody mind if I implemented it that way, i.e., the default for a cache would be that it is not pickled? |
Branch: u/saraedum/ticket/15692 |
Dependencies: #16337 |
Author: Julian Rueth |
comment:7
I'm in support of this although I am not the right person to review the changes. New commits:
|
Commit: |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:10
does not apply, needs rebase |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:13
one failing doctest, see patchbot report |
comment:59
The |
Work Issues: pickle jar |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Changed work issues from pickle jar to none |
comment:63
Looks like your last commit needs a tiny little bit more work
From the bot. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:65
Sorry, that was dumb. I hope it's better now :) New commits:
|
comment:67
Bot happy, I am putting this back to positive. |
Changed branch from u/saraedum/ticket/15692 to |
Changed commit from |
Changed author from Julian Rueth to Julian Rüth |
In #15278, the hash of graphs was turned into a
@cached_method
. If a cached method is pickled, then the cached value is pickled as well. In the case of a hash value, this is not always what we want, since the hash value might depend on the memory address of an object, or worse: The hash function might change in future implementations.That's to say: If you save object O now, together with hash value 123, and later load it, then hash(O) will still be 123, even if a newly constructed object P with O==P might have hash(P)==456, because of a change in the hash function.
This obviously is a problem. There is something called
sage.misc.cachefunc.ClearCacheOnPickle
, but I don't know if this would really help in this case. Also, this would clear all cache values at once. Also, I don't know if it works for cached methods that do not take arguments (besideself
).I suggest that we should instead have an optional parameter for
sage.misc.cachefunc.CachedMethodCallerNoArgs
that determines whether or not the cached value is preserved, and use it on graphs (and future applications of cached method on__hash__
).Depends on #16337
CC: @nathanncohen @vbraun @nbruin @novoselt @sagetrac-jkeitel @nthiery
Component: pickling
Keywords: hash, cache, days71
Author: Julian Rüth
Branch:
a18cbf5
Reviewer: Vincent Delecroix, David Roe
Issue created by migration from https://trac.sagemath.org/ticket/15692
The text was updated successfully, but these errors were encountered: