#12004: copying a linear program using Coin solver consumes enormous amounts of
memory
----------------------------------+-----------------------------------------
Reporter: john_perry | Owner: ncohen
Type: defect | Status: new
Priority: major | Milestone: sage-4.8
Component: linear programming | Keywords: linear programming, Coin,
copy, memory
Work_issues: | Upstream: N/A
Reviewer: | Author: john_perry
Merged: | Dependencies:
----------------------------------+-----------------------------------------
Comment(by john_perry):
Replying to [comment:8 ncohen]:
> > Maybe I'm wrong (probably) but the exponential growth suggests to me
that, during the copy, some sort of nesting is going on. If the problem
were merely a failure to deallocate, the growth should be merely linear,
shouldn't it?
>
> Yep, right `O_o`
I was afraid of that.
> > Python has a garbage collector -- is there any way to peek inside the
structure of `P`, and see what constitutes it?
>
> I've got no idea how to do that. And if that were the case, it would
have to deal with Cython too !
I tried it (`import gc; gc.get_referents(P)`). It isn't really helpful.
I also tried the following: instead of calling the copy constructor, I
called the clone method. I'm referring to this function in
`OsiCbcSolverInterface.hpp`:
{{{
virtual OsiSolverInterface * clone(bool copyData = true) const;
}}}
That required modifying the `.pxd` file, of course. I got it to compile &
run, but the memory problems persist. Still chugging away at this...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12004#comment:9>
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.
