My original intent with respect to caching was that the parents would
be the root objects, and everything else would be lazily referenced
except through them, but just pushing things through was a large
enough task that I never got this done. In particular, what I was
thinking is that a coercion or action involving R and S would have a
lifetime of min(lifetime(R), lifetime(S)) and not keep R or S alive.
If R + S -> R', then this action would keep R' alive, and once R or S
were reallocated R' would be as well (assuming it wasn't referenced
elsewhere). This would reflect use well, but could be quadratic in the
number of live parents if the full crossproduct of interactions was
explored.
+1 to the ring buffer idea as well. Though not as complete, it could
be reasonably large and still prevent memory leaks. In terms of
performance, I wonder if sage/schemes does a lot of large, external
operations (e.g. pari or factoring or non-coercion-requiring
arithmetic). What's the slowdown for ZZ * RDF for this patch?
- Robert
On Tue, Jan 17, 2012 at 2:44 AM, Simon King <simon.k...@uni-jena.de> wrote:
> Hi!
>
> Currently, I try to fix several memory leaks, namely at trac ticket
> #715, #11521, #12215 and #12313. The common idea is: Use weak
> references for the caches (in particular for caching coercions and
> actions), so that stuff can be collected once it is no more used.
>
> But of course it would be easy to overdo it. For example, with the
> current patch from #715, the following computation involves the
> creation of 481 actions, while it only needs 320 actions without the
> patch:
>
> E = J0(46).endomorphism_ring()
> g = E.gens()
>
> So, in that example, actions seem to be garbage collected although
> they will be used again. However, other examples involving elliptic
> curves (e.g., EllipticCurve('960d1').prove_BSD()) are fine, the same
> number of actions is created with or without the patch.
>
> Now I wonder what you would recommend to do?
>
> * Is there a Python package that provides "soft" references (that is
> stronger than a weak reference)? That would be a good solution, but
> google has not been able to find it.
>
> * Should I try to trace down "E.gens()" and add a reference to some
> parent in an appropriate location, so that the 160 actions in the
> example above are prevented from being collected? That would solve the
> particular problem, but there is no guarantee that it is the only
> example of that type.
>
> * Should I modify my weak version of
> `sage.structure.coerce_dict.TripleDict` so that strong references are
> used in the first place, but so that the oldest references are
> "weakened" when the dictionary grows bigger than a certain threshold?
> That is likely to fix the example above and other types of examples as
> well, but may create an overhead.
>
> * Should I consider it as the price to pay for fixing memory leaks?
>
> Best regards,
> Simon
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
