I simplified the memory management section of the FAQ so it now simply
defines a relatively safe set of allowed actions.
Friedrich Foerster wrote:
thanks.
removing the inheritance of Model and the __del__ statement for the
restraints eventually resolved the issue.
i would recommend putting infos like these into a "Dos and Don't Dos"
file or so at an intuitive location for keeping others from running
into similar trouble.
cheers
frido
On Jan 20, 2009, at 11:36 PM, Daniel Russel wrote:
I haven't had a chance to look into it in great depth, but just some
quick comments:
- you should never call __del__ on a restraint (or score state, or
Particle) directly as they are ref counted within C++. I think swig
maps just calls onto a no-op, but I'm not quite sure.
- in general, you avoid inheriting from classes except for those
which are explicitly designed to be inherited from (i.e. it is OK to
inherit from Restraint, but not so great from Model). You should
instead wrap them (i.e. have assembly take a Model as an argument).
There are several reasons for this: first, wrapping is much more
flexible and less likely to result in you having to go back and
change things later; second, in the IMP case, SWIG memory management
is generally problematic and inheriting from a C++ object in python
makes things more complicated. It appears that this is your problem
as removing the assembly class and putting the relevant code inline
in the loop makes the problem go away.
- from my understanding of python, there is no reason to have all the
__del__ calls all over the place. Python does reference counting, so
simply assigning xxx to the next assembly will make assembly go away.
I suspect, as in C++, you shouldn't write a destructor unless you
have a really good reason and know what you are doing.
On Jan 20, 2009, at 1:56 PM, Friedrich Foerster wrote:
hi all,
somehow i keep on stealing my computer memory when running imp from
python.
either my awkward programming style or a bug in imp/swig steals the
memory from my system. attached is an example illustrating the
problem. if you monitor the memory usage, you'll see the consumed
memory gradually increasing - although the same variable is used
throughout the loop. thus, apparently new memory is constantly
allocated and i have no clue what happened to the old one. needless to
say the code could eventually kills every system given the loop is
large enough.
any help on the whereabouts of my memory would be greatly
appreciated...