newbie question - remove a module from ram

J

john fabiani

Hi,

I believe I have good understanding of import but it occurred to me that
I might want to remove an imported module. I.e I load a module into ram
and I no longer need the module. Modules just stays in ram? In the
windows world I would "thisform.release()" and the garbage collector
would release the ram. So did I miss something or is there no release
method. How about a method within a class like destroy()?

I just got to believe it's there???? But where?
John
 
P

Paul McGuire

john fabiani said:
Hi,

I believe I have good understanding of import but it occurred to me that
I might want to remove an imported module. I.e I load a module into ram
and I no longer need the module. Modules just stays in ram? In the
windows world I would "thisform.release()" and the garbage collector
would release the ram. So did I miss something or is there no release
method. How about a method within a class like destroy()?

I just got to believe it's there???? But where?
John

Well, you were pretty close with calling something like .release(). Use the
del statement.
Traceback (most recent call last):

-- Paul
 
P

Paul McGuire

Peter Otten said:
Paul said:
Well, you were pretty close with calling something like .release(). Use
the del statement.

Traceback (most recent call last):

and then
import sys
sys.modules["random"].random() 0.43459738002826365

should make it clear that (next to) no memory is freed in the process.

Peter
So then what if he follows up with:

del sys.modules["random"]

Are there any other dangling references to this module that would stymie the
garbage collector (assuming that the OP hasn't saved off his own reference
to the module)?

-- Paul
 
P

Peter Otten

Paul said:
Peter Otten said:
Paul said:
Hi,

I believe I have good understanding of import but it occurred to me that
I might want to remove an imported module. I.e I load a module into ram
and I no longer need the module. Modules just stays in ram? In the
windows world I would "thisform.release()" and the garbage collector
would release the ram. So did I miss something or is there no release
method. How about a method within a class like destroy()?

I just got to believe it's there???? But where?
John

Well, you were pretty close with calling something like .release().
Use the del statement.

import random
print random.random()
0.475899061786
del random
print random.random()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'random' is not defined

and then
import sys
sys.modules["random"].random() 0.43459738002826365

should make it clear that (next to) no memory is freed in the process.

Peter
So then what if he follows up with:

del sys.modules["random"]

Are there any other dangling references to this module that would stymie
the garbage collector (assuming that the OP hasn't saved off his own
reference to the module)?

Python 2.3.3 (#1, Jan 3 2004, 13:57:08)
[GCC 3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import random, sys, weakref
sys.getrefcount(random) 3
del sys.modules["random"]
sys.getrefcount(random)
2

This is one reference for the function call and one for the __main__.random
reference, i. e. reference count should indeed go to zero if we perform

del random

I could not trick the module into telling me directly:
Traceback (most recent call last):

Second try, working around the limitations of weak references:
import random, sys, weakref
class Flag: pass ....
random.flag = Flag()
def goodbye(r): print "I'm gone" ....
w = weakref.ref(random.flag, goodbye)
del random
del sys.modules["random"] I'm gone

So at least the objects in the module are garbage-collected.

Peter
 
J

john fabiani

Paul said:
Paul McGuire wrote:

Hi,

I believe I have good understanding of import but it occurred to me
that
I might want to remove an imported module. I.e I load a module into
ram
and I no longer need the module. Modules just stays in ram? In the
windows world I would "thisform.release()" and the garbage collector
would release the ram. So did I miss something or is there no release
method. How about a method within a class like destroy()?

I just got to believe it's there???? But where?
John

Well, you were pretty close with calling something like .release(). Use
the del statement.


import random
print random.random()

0.475899061786

del random
print random.random()

Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'random' is not defined
and then

import sys
sys.modules["random"].random()

0.43459738002826365

should make it clear that (next to) no memory is freed in the process.

Peter

So then what if he follows up with:

del sys.modules["random"]

Are there any other dangling references to this module that would stymie the
garbage collector (assuming that the OP hasn't saved off his own reference
to the module)?

-- Paul
I think I follow: but doesn't the garbage collector decide what is to
be done? Assuming that there were no dangling references wouldn't the
ram be available for re-use?
John
 
T

Terry Reedy

john fabiani said:
Hi,

I believe I have good understanding of import but it occurred to me that
I might want to remove an imported module. I.e I load a module into ram
and I no longer need the module. Modules just stays in ram? In the
windows world I would "thisform.release()" and the garbage collector
would release the ram. So did I miss something or is there no release
method. How about a method within a class like destroy()?

I just got to believe it's there???? But where?

The delete statement, in general, directs the interpreter to delete the
association between a name or any other slot and the previously associated
object. Ditto for function locals at function return. It does not tell
the interpreter what to do with a object when its last association
disappears. If, for a particular implementation, it makes sense to talk of
the object being in 'deletable memory' (and, for humans, it hardly does,
nor would it for read-only machine memory, nor, possibly, for 'builtin'
modules), then the standard *allows* but does not *require* deletion.

CPython currently caches a reference to modules so that code like the
following won't tear down a module as it returns and have to rebuild it at
every call:

def sincos(x):
import math as m # for the purpose of this example, assume this is only
math import
return sin(x), cos(x)

Modules are sufficiently small, sufficiently expensive to set up, and
sufficiently often reused, that I has not been thought worthwhile to add a
modwipe function to countervail the cache effect, which itself was added to
countervail the usual CPython delete-object- with-last-reference behavior.

Terry J. Reedy
 
M

Michael Hudson

john fabiani said:
Paul said:
So then what if he follows up with:
del sys.modules["random"]
Are there any other dangling references to this module that would
stymie the
garbage collector (assuming that the OP hasn't saved off his own reference
to the module)?
-- Paul
I think I follow: but doesn't the garbage collector decide what is to
be done? Assuming that there were no dangling references wouldn't
the ram be available for re-use?

Well, that depends on vagaries of your allocator, but probably.

Why are you so worried about the RAM your modules take up?

Cheers,
mwh
 
J

john fabiani

Michael said:
Paul said:
So then what if he follows up with:
del sys.modules["random"]
Are there any other dangling references to this module that would
stymie the
garbage collector (assuming that the OP hasn't saved off his own reference
to the module)?
-- Paul

I think I follow: but doesn't the garbage collector decide what is to
be done? Assuming that there were no dangling references wouldn't
the ram be available for re-use?


Well, that depends on vagaries of your allocator, but probably.

Why are you so worried about the RAM your modules take up?

Cheers,
mwh
Well I guess I don't have an example that I can bring up. It's just an
after thought that if I create a large program that everything is being
stored in ram (or swap). At some point I'll run out of ram and the more
I limit the stuff I load and can't release the better. In the windows
world I release(). When I monitor the ram usage (task manager) I can
see the ram usage lower when I release(). I keep thinking about all the
forms and the associated code I load in my windows programs. If I kept
all the forms in ram I'd run out quickly. Of course I work with
accounting packages....
John
 
S

Steve Holden

Terry said:
The delete statement, in general, directs the interpreter to delete the
association between a name or any other slot and the previously associated
object. Ditto for function locals at function return. It does not tell
the interpreter what to do with a object when its last association
disappears. If, for a particular implementation, it makes sense to talk of
the object being in 'deletable memory' (and, for humans, it hardly does,
nor would it for read-only machine memory, nor, possibly, for 'builtin'
modules), then the standard *allows* but does not *require* deletion.

CPython currently caches a reference to modules so that code like the
following won't tear down a module as it returns and have to rebuild it at
every call:

def sincos(x):
import math as m # for the purpose of this example, assume this is only
math import
return sin(x), cos(x)

Modules are sufficiently small, sufficiently expensive to set up, and
sufficiently often reused, that I has not been thought worthwhile to add a
modwipe function to countervail the cache effect, which itself was added to
countervail the usual CPython delete-object- with-last-reference behavior.

Terry J. Reedy
Note also that there is, AFAICT, no way to reclaim space occupied by the
code of extension modules.

regards
Steve
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top