#12616: The LP are not deallocated because of cyclic references !
----------------------------------+-----------------------------------------
Reporter: ncohen | Owner: ncohen
Type: defect | Status: needs_review
Priority: major | Milestone: sage-5.0
Component: linear programming | Keywords:
Work_issues: | Upstream: N/A
Reviewer: | Author: Nathann Cohen
Merged: | Dependencies:
----------------------------------+-----------------------------------------
Changes (by SimonKing):
* work_issues: Add doctest =>
Comment:
Replying to [comment:7 ncohen]:
> Well, the first reason is that with this line added between the two, the
answer is 0 whether the patch is applied or not.
Then there is either no memory leak, or the leaking object is not
`MixedIntegerLinearProgram`.
> Using gc.collect() was actually Volker's first answer to the sage-devel
thread which totally solved the problem : the instances of
MixedIntegerLinearProgram are indeed deallocated by the garbage collector
when it is *called*, which is not done systematically when the function
ends.
That's just the usual behaviour of garbage collection.
> Robert Bradshaw and William then said that if there was no cyclic
dependency the work would be done without the garbage collector's help at
the end of the function, which is actually the case.
>
> Hence, in this situation, the doctest fails when the patch is not
applied, and according to their answers (and experience until now) has no
reason to fail when the patch is applied. What do you advise ?
Hm. Difficult.
When you say "memory leak", I expect something like
{{{
sage: for p in prime_range(10^5):
....: K = GF(p)
....: a = K(0)
....:
}}}
Here, the line `a = K(0)` creates a coercion from `ZZ` to `K`, and without
#715 and #11521 coercion maps ''together with domain and codomain'' are
cached and will thus stay in memory forever, soon eating up your
computer's brain.
But when you say that the garbage collector can successfully collect the
`MixedIntegerLinearProgram` when explicitly do the collection, then it
should be the case that sooner or later it will be collected
automatically.
In fact, it is the case:
{{{
sage: def just_create_variables():
....: for n in range(1000):
....: p = MixedIntegerLinearProgram()
....: b = p.new_variable()
....: p.add_constraint(b[3]+b[6] <= n)
....: p.solve()
....: print n,get_memory_usage()
....:
sage: just_create_variables()
0 842.51171875
1 842.671875
2 842.671875
3 842.671875
4 842.671875
5 842.8359375
6 842.8359375
...
993 846.75
994 846.75
995 846.75
996 846.75
997 846.75
998 846.75
999 846.75
}}}
OK, the memory consumption mildly increases, but the instances of the
mixed integer linear program are collectable:
{{{
sage: len([x for x in gc.get_objects() if
isinstance(x,MixedIntegerLinearProgram)])
---------------------------------------------------------------------------
NameError Traceback (most recent call
last)
/home/SimonKing/<ipython console> in <module>()
NameError: name 'gc' is not defined
sage: import gc # Oops...
sage: len([x for x in gc.get_objects() if
isinstance(x,MixedIntegerLinearProgram)])
8 # only 8, even though 1000 were created!!
sage: gc.collect()
100
sage: len([x for x in gc.get_objects() if
isinstance(x,MixedIntegerLinearProgram)])
0
}}}
That is with vanilla sage-4.8 on sage.math. So, I'd say there was no leak!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12616#comment:8>
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.
