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