#12808: Optimize ClassCallMetaClass using Cython
--------------------------------------------------+-------------------------
Reporter: hivert | Owner: jason
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.0
Component: misc | Resolution:
Keywords: classcall UniqueRepresentation | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Florent Hivert, Simon King | Merged in:
Dependencies: | Stopgaps:
--------------------------------------------------+-------------------------
Comment (by hivert):
Hi Simon,
Thanks again for those very precise timing measures. I'm sorry I wasn't
completely clear on the timing I wanted to have. Here is what I hope is a
clearer explanation:
There is a common usage of {{{ClasscallMetaclass}}} and
{{{__classcall_private__}}} for elements in order to delegate the creation
to
the parent. For example, the call
{{{
sage: PerfectMatching([(1,2),(3,4)])
PerfectMatching [(1, 2), (3, 4)]
}}}
actually create the parent:
{{{
sage: P4 = PerfectMatchings(4); P4
Set of perfect matchings of {1, 2, 3, 4}
}}}
And calls
{{{
sage: P4([(1,2),(3,4)])
PerfectMatching [(1, 2), (3, 4)]
}}}
This is done by a classcall trick. There isn't currently a lot of this
trick
in Sage library but many more are coming from the Sage-combinat queue.
Now I don't see any element class having a nested class. So in an ideal
world,
we'd like to have {{{PerfectMatching}}} in {{{ClasscallMetaclass}}} but
not in
{{{NestedClassMetaclass}}}. From your timings, I clearly see that being in
{{{NestedClassMetaclass}}} doesn't impact creation of the element, but I
was
wondering how it impact the creation of the class {{{element_class}}}
itself. As I said, I don't currently see any usecase where we will create
a
lot of {{{element_class}}} but who knows...
So here are the timings:
{{{
sage: from sage.misc.classcall_metaclass import ClasscallType
sage: from sage.structure.element import Element
sage: %timeit type('toto', (Element,), {})
625 loops, best of 3: 25.9 µs per loop
sage: %timeit ClasscallType('toto', (Element,), {})
625 loops, best of 3: 31 µs per loop
}}}
With your patch cdefing {{{NestedclassMetaclass}}}, there is a slight
overhead
in being in {{{NestedClassMetaclass}}}:
{{{
sage: %timeit ClasscallMetaclass('toto', (Element,), {})
625 loops, best of 3: 36.9 µs per loop
}}}
The overhead is quite similar when {{{NestedclassMetaclass}}} is not cdef:
{{{
sage: %timeit ClasscallMetaclass('toto', (Element,), {})
625 loops, best of 3: 37.2 µs per loop
}}}
Now this case is not very realistic since there are no methods in the new
class. Let's put some by getting a realistic dictionary:
{{{
sage: dct = dict(PerfectMatching.__dict__)
sage: len(dct)
24
}}}
With a cdef {{{NestedclassMetaclass}}}
{{{
sage: %timeit type('toto', (Element,), dct)
625 loops, best of 3: 27 µs per loop
sage: %timeit ClasscallType('toto', (Element,), dct)
625 loops, best of 3: 31.7 µs per loop
sage: %timeit ClasscallMetaclass('toto', (Element,), dct)
625 loops, best of 3: 48.9 µs per loop
}}}
Without a cdef {{{NestedclassMetaclass}}}
{{{
sage: %timeit type('toto', (Element,), dct)
625 loops, best of 3: 28.8 µs per loop
sage: %timeit ClasscallType('toto', (Element,), dct)
625 loops, best of 3: 32.5 µs per loop
sage: %timeit ClasscallMetaclass('toto', (Element,), dct)
625 loops, best of 3: 50.6 µs per loop
}}}
As a conclusion in some realistic usecases: the slowdown for having
{{{ClasscallMetaclass}}} systematically inheriting from
{{{NestedclassMetaclass}}}, that is no {{{ClasscallType}}} is 48.9 µs vs
31.7
µs. This is non negligible (after all calling the
{{{modify_for_nested_pickle}}} indeed has a cost) but much less that I
expected. Since I see no realistic usage in creating a lot of such
classes, I
think I'm Ok with your second patch. I'd like to have Nicolas opinion on
that,
since he is the one that raised this question.
I'm reviewing your two patches (after having lunch).
Florent
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12808#comment:45>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.