#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:
-------------------------------+--------------------------------------------
Comment (by tscrim):
Replying to [comment:7 nbruin]:
> 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.
I was thinking of creating elements from parent objects, which I'd imagine
does an attribute lookup of `_element_class`. But this would only receive
a benefit for cdef parents. Anyways, I'm happy with the way this ticket
is. Plus the patchbot says there's no real change in the startup time, and
`lazy_attribute` is (typically) loaded/imported then.
> 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`.
Probably best left to another ticket.
> > 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.
For the documentation, a good name and a good description in at the class
level should be sufficient. (Although in some ways having it as an
attribute makes it feel more mutable to me, but I don't want to really
open that can of worms.)
Thanks for answering all my questions.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14615#comment:8>
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.
