#8905: Memory leak in echelon over QQ
--------------------------------------+--------------------------
Reporter: SimonKing | Owner: tbd
Type: defect | Status: needs_work
Priority: major | Milestone: sage-6.6
Component: memleak | Resolution:
Keywords: memleak echelonize | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
--------------------------------------+--------------------------
Comment (by nbruin):
Replying to [comment:11 mmezzarobba]:
> No, you are right, I misread the results. It looks like we are still
leaking about 16 bytes per call.
I wouldn't be so quick to conclude linear behaviour from so few data
points. I'm getting:
{{{
1130.9375 1
1131.1875 5107
1131.4375 22580
1131.6875 39743
}}}
and no further increase up to `n=738068` (after which I gave up).
Echelonization over QQ likely leads to very complicated memory use (lots
of allocation/deallocation), so together with non-deterministic gc
(because parents only clear on triggered GC) you expect that the memory
layout shows a lot of short-term fluctuations: fragmentation will lead to
slowly increasing memory footprint; hopefully stabilizing over long
periods. The numbers above are quite consistent with that. Certainly
gc.objects() is not showing any significant object accumulation, so any
leak would have to be outside python.
I see no indication of a memory leak here anymore, but I guess you could
valgrind it to be certain.
--
Ticket URL: <http://trac.sagemath.org/ticket/8905#comment:12>
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.
For more options, visit https://groups.google.com/d/optout.
