#14159: Don't install callbacks on values of TripleDict, MonoDict
------------------------------+---------------------------------------------
Reporter: nbruin | Owner: tbd
Type: defect | Status: needs_review
Priority: major | Milestone: sage-5.8
Component: memleak | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers: Nils Bruin
Authors: Simon King | Merged in:
Dependencies: #13387 | Stopgaps:
------------------------------+---------------------------------------------
Comment (by nbruin):
Replying to [comment:38 SimonKing]:
> 1. I found that a dozen of homsets are created ''and'' deleted during
startup. One should find where they are created, and see whether their
creation is really needed or whether one can avoid that the get deleted.
"Premature optimization is the root of all evil" [Knuth]. Does their
creation and deletion add considerably to the startup time? I would expect
that this gets dwarfed by all the work involved in constructing class
instances and resizing the globals dictionary.
> 2. `MonoDict` and `TripleDict` have fast cdef set and get methods, but
they are not always used. At least in Cython modules, we should try to
find all locations which could benefit from replacing `T[a,b,c]` by
`T.get(a,b,c)`. And even for Python modules, I think it would make sense
to turn the cdef get and set methods into cpdef get and set methods: I
guess it would still be faster then `T[a,b,c]`, because one avoids the
test
Probably not: The `__setitem__` and `__getitem__` lookups in python likely
happen faster than normal method lookups in python, because the special
methods are stored in slots, whereas normal method lookups have to resort
to dictionary lookups. That might well cancel the packing/unpacking that
needs to happen for the key (which isn't necessary for `MonoDict` at all,
by the way).
I think to do optimizations with best productivity:
- locate scenarios where `MonoDict` and `TripleDict` access is
significant in time usage
- Find what is creating the worst overhead.
I'm not sure that the sage startup routine is most representative of that
behaviour.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14159#comment:39>
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.