On 30 Apr., 19:12, Nils Bruin <nbr...@sfu.ca> 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
To post to this group, send an email to firstname.lastname@example.org
To unsubscribe from this group, send an email to email@example.com
For more options, visit this group at http://groups.google.com/group/sage-devel