0

In my code, I create a list of objects inside a for-loop. Something like this: (The get_size functions was obtained from here: How do I determine the size of an object in Python?)

def mem_now():
    mem = psutil.Process(os.getpid()).memory_info()
    mem = mem[0]/(1024.**2)
    return mem

class lista():
    def __init__(self, val):
        self.x = val
        self.y = val**2
        self.z = val - 1

intlst = []
objlst = []

for i in range(int(1e5)):
    g = lista(i)
    objlst.append(g)
    intlst.append(g.z)

print 'int_list_size = {:.2f} Mb'.format(get_size(intlst)/1e6)
print 'obj_list_size = {:.2f} Mb'.format(get_size(objlst)/1e6)

print 'mem_now (no del) = {:.2f} Mb'.format(mem_now())

del intlst

print 'mem_now (del int) = {:.2f} Mb'.format(mem_now())

del objlst

print 'mem_now (del obj) = {:.2f} Mb'.format(mem_now())

and the output is as follows:

mem_now = 45.11 Mb

int_list_size = 3.22 Mb
obj_list_size = 43.22 Mb

mem_now (no del) = 103.35 Mb
mem_now (del int) = 103.35 Mb
mem_now (del obj) = 69.10 Mb

As you can see, after deleting the lists, I still haven't cleared all the memory. The more attributes and the more iterations I run, the more the final memory value is. I want to complete delete all the objects I created, how can I do that?

martineau
  • 119,623
  • 25
  • 170
  • 301
  • You can try to import the python garbage collector `import gc` and then calling the collection manally, as `gc.collect()` – Marco Sep 10 '20 at 01:44
  • Thanks Marco, but it doesn't really help. In this particular example, it would reduce the last mem value to 68.07 Mb – GIOVANNI QUINONES VALDEZ Sep 10 '20 at 01:48
  • 2
    You cannot manually delete objects in Python. `del` doesn't delete objects, it deletes name, i.e. references – juanpa.arrivillaga Sep 10 '20 at 01:51
  • 1
    @Marco that won't make a difference here. `gc` only controls the cyclic garbage collector, which takes care of cyclic references, there are none being created here. CPython uses reference counting, when a reference count reaches 0, objects are reclaimed immediately. – juanpa.arrivillaga Sep 10 '20 at 02:02
  • Even if you could directly force the object to be freed at the C level, the *operating system* might *still* decide to hold onto that memory for the process. (It's actually quite likely to, as long as no other process wants the memory). Not to mention that there are potentially multiple layers of address space virtualization involved. This is simply beyond your control on modern platforms. – Karl Knechtel Sep 10 '20 at 02:28

1 Answers1

1

I want to complete delete all the objects I created, how can I do that?

You did. You don't even need to use del (all that del does is remove a reference; the underlying object is cleaned up when there are no more references to it).

Consider a simpler example:

def alloc():
    global x
    x = list(range(1000000))

for i in range(1000):
    alloc()

We repeatedly create the list from scratch in a loop. Even though we did nothing to "delete" the list from previous iterations (you do not need to, and should not try), we do not run out of memory - because the cleanup is automatic. (If you actually did run out of memory, Python would raise MemoryError for a failed allocation.) x takes about 36 megabytes to represent on my system (8 for the list, and 28 for the integers); I do not have 36 gigabytes of RAM, but there is no problem. It just takes a bit of time (about 19 seconds on my system); memory usage does not creep upwards over time.

When I then del x, on my system the process memory usage - as reported by Task Manager - promptly drops. Here's the thing, though: it might not do so consistently, or at all, or immediately, or it may depend on what tool you use to check. It's likely to depend on your operating system and other platform details. In any event, it's not something you could dream of controlling completely from Python, and I suspect a lot of the time you couldn't even do it from assembly. Don't worry about it. The operating system knows better than you how to assign memory to processes. That's why your computer has one.

Karl Knechtel
  • 62,466
  • 11
  • 102
  • 153