#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.

Reply via email to