Helloooooooo ! > 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.
You are right here, and using cached_methods would not have been an end to our combinatorial design problems. But this function is called so often on the same input that it just cannot work anymore without caching, and so we will just cache everything for the moment. Even if it means returning tuples instead of returning lists because it cannot cache non-immutable stuff, which wouldn't have been a problem with this additional feature as we wouldn't have cached this output anyway. It is just more complicated, and less efficient in the meantime. Plus we have something like three different functions to cache in the same way. Well. It would have been easier for us to only add this #16353 branch :-/ > 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. HMmmmmm... Well, if I cannot add this feature to the caching mechanism I will just write a specific caching for those functions... But really, design code is not the place to implement caching mechanisms... Nathann -- 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.
