If an method is *extremely* performance critical, one might want to give it its own custom cache to avoid as much overhead as possible. I don't think the utility cached_function and cached_method can be expected to have shining performance for all types of functions and inputs.
Also, if one needs really flexible caching then using the utility functions is probably not the way to go. When I need to cache in a sophisticated manner (eg caching only last N calls, or giving cache elements expiration times) I always resort to dogpile.cache [1] instead on the utility functions. Cheers, J [1] https://bitbucket.org/zzzeek/dogpile.cache On Thursday, May 15, 2014 4:57:28 PM UTC+1, Nils Bruin wrote: > > On Thursday, May 15, 2014 12:11:31 AM UTC-7, Nathann Cohen wrote: >> >> I would accept the argument of "speed issue", but of course you cannot >> use that one AND defend the "key" parameter, which has an easier workaround >> than my problem here and a higher cost. So it is both or none, see ? :-P >> > > It's a potentially valid point that the introduction of the "key" > parameter might have affected normal operation, but I just checked: it does > not. At initialization time (i.e., when the decorator creates the wrapping > object), the presence of the key argument is checked and if it's not there, > the exact old code is executed, so if key is not there, it is guaranteed to > not affect runtime performance in any way. *deciding* whether something > needs to be cached will always be a runtime decision. > > The justification is also a little different: "key" doesn't change the > logical operation of the cache. It just provides a way to customize the > normalization of the arguments (which always happens and I think people > underestimate in how costly it can be: arguments to python function can > look awfully complicated and to normalize them in a way that reflects how > python binds them is a lot of work). I some doubts about its current > implementation. Perhaps it should really just provide an *alternative* to > the default argument_fixer.fix_to_pos. Especially the line > > return self.key(*args, **dict(kwargs)) > > worries me a bit. (here `kwargs` is an already processed version of an > incoming `**kwargs`!). I suspect that if this ever turns out to be a widely > used feature, we'll have to have some changes that are incompatible in edge > cases to arrive at a cleaner/more efficient design. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
