Hi! IMHO, the cached_... decorators are currently too slow. It seems to me that too much time is spent for looking up the cache (calling the method get_cache()).
I'd like to invest some work in it, but I need some info: The cache can be * a dictionary self.cache of the decorated function (this is for CachedFunction), * a dictionary-like instance self.cache of class FileCache (this is for DiskCachedFunction), * a dictionary that is an attribute of the instance to which the cached method is bound (this is for CachedMethod), or * a dictionary that is an attribute of the parent of the instance to which the cached method is bound (this is for CachedInParentMethod). Sometimes, looking up the cache requires two calls (get_cache() and _get_instance_cache()). Moreover, C extension types don't provide a __dict__ attribute, which is a problem for CachedMethod and CachedInParentMethod. The cache in the case of CachedFunction and DiskCachedFunction is, of course, easy to find: It is self.cache, where "self" is a CachedFunction (or DiskCachedFunction) instance. Let us now consider CachedMethod. Let x be an instance that has a cached method (or cached in parent method) foo. The __get__ method of CachedMethod turns x.foo into an instance of CachedMethodCaller, that is specific to x. Now, I wonder why the method is not cached in an attribute of the CachedMethodCaller instance. Or explicitly: What is the advantage of caching x.foo in x._cache__foo rather than in x.foo.cache? The disadvantage is that the string "_cache__foo" must be created and then x.__dict__["_cache__foo"] must be obtained, which costs time. Even in the case of CachedInParentMethod, there could still be an attribute x.foo.cache, that points to an attribute of x.parent(). Hence, there would only be one cache (namely in x.parent()), while elements of x.parent() only provide pointers to it, which is both cheap and fast, if I am not mistaken. Best regards, Simon -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
