Hi Nils, On 30 Apr., 19:12, Nils Bruin <[email protected]> wrote: > I looked over the comments in trac #11115 . Thank you for a very > thorough analysis and presentation. One thing I didn't immediately > find in the discussion there is that an increased memory footprint for > elements can also cause cache-misses sooner, so lead to a slowdown
I don't understand that. Can you elaborate? Perhaps on the ticket? > Cache performance is very dependent on processor and very tricky to > test for. However, I would expect that an implementation which uses > less memory for its working set will never perform worse than one that > uses more (other things being equal). So my default preference would > be for the mixed approach (3): make your chance to parents as proposed > and let people install __cached_methods manually on elements to get > the benefits. OK, I'll soon post a patch for version (3) on the ticket, as an alternative to the original implementation. > The drawback of that approach is that it takes very specialized > knowledge to get caching on elements working well. It would need to be > featured prominently in the documentation somewhere. I somehow disagree: I believe that it would take very specialized knowledge in order to create an example that exposes the problem: You need to implement a class whose instances don't accept attributes (so, that is likely to require Cython), and in addition an instance must belong to a parent that belongs to a category that provides a cached element method (does that exist, yet?). And then, you must write code that relies on that method being cached. But certainly, if we go for version (3) then I will add an example in sage.misc.cachefunc. 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
