#14592: Use lazy strings for error messages in coercion
-----------------------------------------------+----------------------------
Reporter: SimonKing | Owner: tbd
Type: enhancement | Status: new
Priority: major | Milestone: sage-5.10
Component: performance | Resolution:
Keywords: lazy error message coercion | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: #14585 | Stopgaps:
-----------------------------------------------+----------------------------
Comment (by nbruin):
Replying to [comment:2 SimonKing]:
> Do you have a striking example, in which computing a string
representation for creating an error message really hurts?
If there's an error message that includes the string representation of a
matrix you'd see a huge difference (but it looks like changing the matrix
string rep is the more appropriate solution) if you manage to produce and
catch that error in the inner loop.
Otherwise, we should just keep this ticket on the backburner and know it's
an optimization we can use if it matters.
There are pros and cons besides performance to this approach:
- With a lazy string message you have access to the objects involved in
the error itself, even if they were produced in cython code (for python
code you could probably get at them with a debugger and the stackframe).
Sometimes picking apart the objects themselves helps in understanding
where they're coming from (or you can look them up in memory using
`gc.get_referrers`).
- More complicated objects might be kept alive with lazy strings, because
they hold references. Exceptions tend to be rather transient, though, and
the frame stack (which would also still be alive in the `try...except`)
would probably hold references as well.
It seemed like such an obvious speedup for python's "easier to ask
forgiveness" programming style that produces and catches exceptions left
and right, but if it doesn't seem to have a significant impact, we
probably shouldn't bother.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14592#comment:3>
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.
