#13400: Use strong caches diligently
-------------------------------+--------------------------------------------
       Reporter:  nbruin       |         Owner:  robertwb     
           Type:  enhancement  |        Status:  new          
       Priority:  major        |     Milestone:  sage-wishlist
      Component:  coercion     |    Resolution:               
       Keywords:               |   Work issues:               
Report Upstream:  N/A          |     Reviewers:               
        Authors:               |     Merged in:               
   Dependencies:               |      Stopgaps:               
-------------------------------+--------------------------------------------

Comment (by nbruin):

 That looks like quite an impressive gain. Given that you already have a
 good way of analysing doctest timing per-file, would you see what the
 effect is?

 "Premature optimization is the root of evil" (Knuth): We shouldn't
 actually be optimizing doctests blindly. We can use them as a guide to
 find gross inefficiencies and repair those. My general feeling is that
 reducing the overhead on producing finite fields and related structures
 should be a big benefit generally, but we should only go down that path if
 we can corroborate that.

 I was a bit surprised to see that caching "popular multimodular" fields
 didn't make much of a difference after fixing Thierry's code for an
 example where I though it would. It may still be a good idea but I don't
 have evidence that it matters.

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