#14615: cythonize lazy_atrtibute
-------------------------------+--------------------------------------------
Reporter: nbruin | Owner: tbd
Type: enhancement | Status: positive_review
Priority: major | Milestone: sage-5.10
Component: performance | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers: Travis Scrimshaw
Authors: Nils Bruin | Merged in:
Dependencies: | Stopgaps:
-------------------------------+--------------------------------------------
Changes (by nbruin):
* status: needs_review => positive_review
Comment:
Replying to [comment:6 tscrim]:
> Then should we expect this result in a speedup for creating parent
objects?
No, not for creation. That's the trick of a ''lazy'' attribute -- it
doesn't incur a cost upon creation (instead it's sitting ready on the type
(Parent in this case) to instantiate the attribute when required.
What does get sped up is ''first access'' of the attribute. If the object
in question has a dict, it doesn't matter which implementation we have
afterwards: it's just a regular `__dict__` lookup from then on.
The only case where it really matter is for types that ''don't'' have an
instance dict, such as cython cdef classes, because the `__cached_method`
lookup has to be done every time. We could speed that up even further (at
the cost of flexibility) by casting `instance` to `Parent` before fetching
`__cached_method`. We'll then get a straight `C struct` access in cython
instead of a `getattr`.
> However `lazy_attribute` isn't an extension class since it isn't
`cdef`'ed, correct? In either case, could we do something similar to
`cached_method` to get around any penalties
Correct, but it inherits the relevant slots from a `cdef` class. That's
where the speed increase comes from. The penalties I was thinking of was
memory footprint and sage startup cost. I don't know if loading a `.so` is
faster or slower than a `.pyc` (my guess is slower).
> (I believe `cached_method` can be/is faster than python attribute
lookup)?
No, that's an artifact of cython classes not participating in the
attribute lookup cache. That's fixed with cython 0.19.1. That is because
many sage objects have very deep MROs and since an instance attribute can
be shadowed by a data descriptor ''anywhere'' in the MRO, it always had to
walk all of it. That's fixed now.
Straight attribute lookup should always be faster than looking up a method
and calling the method. because the method lookup has the same cost as
looking up an attribute (modulo CPU memory and cache idiosyncrasies of
course)
> Or is the penalty you're referring to a loading/startup penalty?
yes, that's what I meant.
> Actually, one more question/comment, shouldn't `lazy_attribute` be
faster than `chached_method` with no arguements?
It should, for the reason above, but only with cython >= 0.19.1
> I think we should be merging (some version of) this ticket precisely for
the reason you stated.
Your point about `cached_method_noargs` is a good one. However, removing
the parentheses in all sage code might prove difficult to accomplish. But
yes, I think people should prefer lazy attributes over cached_methods for
performance. They are harder to document accessibly, however (the
convention now seems to be that you can look up the descriptor on the type
rather than the instance so rather than
compare:
{{{
sage: V.dim_as_cached_method?
//gives doc if it's a method
sage: V.dim_as_cached_method()
//gives the dimension
sage: V.dim_as_attribute?
//gives the doc of an integer object!
sage: V.dim_as_attribute
//because this is the dimension already
sage: type(V).dim_as_attribute?
//would give the doc
}}}
Can people get used to that? Only if we merge the ticket. I guess we
should then.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14615#comment:7>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
