#14058: Weakly reference binary operation codomains
-----------------------------------+----------------------------------------
       Reporter:  robertwb         |         Owner:  rlm         
           Type:  enhancement      |        Status:  needs_review
       Priority:  major            |     Milestone:  sage-5.7    
      Component:  memleak          |    Resolution:              
       Keywords:                   |   Work issues:              
Report Upstream:  N/A              |     Reviewers:              
        Authors:  Robert Bradshaw  |     Merged in:              
   Dependencies:  #12313           |      Stopgaps:              
-----------------------------------+----------------------------------------

Comment (by nbruin):

 Replying to [comment:16 SimonKing]:
 > I think it is not acceptable that a multiple creation is triggered.
 ...
 Why not? Should the user expect that doing something a second time is
 faster than the first, without taking special precautions?

 > In your example, `GF(p)[xi]` is created exactly once, for each value of
 p and i. Clearly, in this situation it would not make sense to keep it
 alive, because it is never reused. However, I doubt that this is a typical
 use case.

 But how do you tell the difference? Against too little caching there is a
 simple defense: keep a reference yourself. Against too much caching there
 is nothing you can do. You just run out of memory because data structures
 outside your control blow up.

 We clearly have too much caching presently, in some cases by design. I
 think we first need a design that's fairly clean and for which we can
 reliably reason there's not "too much" caching (changing the order of
 memory requirement is definitely "too much" for me). Next step is tweaking
 it, possibly with MRU queues (which in that case should really be
 investigated for interfering with efficient GC, which is based on "objects
 either live very short or very long", so artificially creating objects
 with a medium lifespan is bad)

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


Reply via email to