#12313: Fix yet another memory leak caused by caching of coercion data
--------------------------------------------------------+-------------------
       Reporter:  SimonKing                             |         Owner:        
                                               
           Type:  defect                                |        Status:  
needs_work                                           
       Priority:  major                                 |     Milestone:  
sage-5.7                                             
      Component:  memleak                               |    Resolution:        
                                               
       Keywords:  coercion weak dictionary              |   Work issues:        
                                               
Report Upstream:  N/A                                   |     Reviewers:  Simon 
King, Jean-Pierre Flori, John Perry, Nils Bruin
        Authors:  Simon King, Jean-Pierre Flori         |     Merged in:        
                                               
   Dependencies:  #715, #11521, #12215, #13746, #13378  |      Stopgaps:        
                                               
--------------------------------------------------------+-------------------

Comment (by nbruin):

 Had a quick look. To simplify and speed up the tests a little bit, you can
 concentrate on one of the tests that's slow:
 {{{
 sage: cmd='dks4._test_associativity()'
 sage: import cProfile,pstats
 sage: s=pstats.Stats(cProfile.Profile().runctx(cmd,globals(),{}))
 sage: S=s.sort_stats('cumulative')
 sage: S.print_stats()
 ...
 sage: S.print_callers()
 ...
 }}}
 the latter one essentially gives you the call graph, weighted by time
 contributed.

 In fact it shows you pretty quickly that ShurFunctions were apparently
 VERY heavily relying on parents being cached:
 {{{
 X=dks4[0]+ 2*dks4[1] + 3*dks4[2]
 (X*X)*X #wait quite a long time
 }}}
 This mainly uses `dks4.product` and you can follow the code from there to
 see this has not been written with runtime optimization in mind. Probably
 if you make some things cached the way there, you'll regain the original
 performance.

 My first impression is that this code indeed will make a concrete
 realization of some structure, perform the operation, and throw away the
 concrete realization. Elements on the way basically ARE homs, hence all
 the homsets. I'm sure someone will be grateful if you clean up this
 design, but I'm not so sure it should be part of this ticket or a
 requirement for its merger. Good luck!

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12313#comment:283>
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