Does this code create a memory leak in python?

Question

Consider the following code for illustration propose:

import mod

f1s = ["A1", "B1", "C1"]
f2s = ["A2", "B2", "C2"]

for f1, f2 in zip(f1s,f2s):

    # Creating an object
    acumulator = mod.AcumulatorObject()

    # Using object
    acumulator.append(f1)
    acumulator.append(f2)

    # Output of object
    acumulator.print()

So, I use an instance of a class at the beginning of the for to perform an operation. For each tuple in the for I need to perform the same action, however I can not use the same object because it would add the effect of the last iteration. Therefore, at the beginning of every iteration I create a new instance.

My question is if by doing this a memory leak is created? What action I have to do for each object created? (Delete it maybe? Or by assign the new object to the same name it is cleared?)

As far as I understand, once the reference count reaches zero the object is garbage collected in the next GC cycle. So the answer is no, since the variable `acumulator` will no longer point to the object created in the previous loop iteration the GC will wipe it in the next pass and there is no need to do it explicitly. — Paulo Scardine, Feb 28 '18 at 18:01
This won't cause any problems with Python. Python is a memory-managed language, here, reference-counting will take care of reclaiming the objects. — juanpa.arrivillaga, Feb 28 '18 at 18:09
@juanpa.arrivillaga altough you should be concerned about system resources like file pointers - specially on implementations that do not use reference counting for GC - notably Pypy, Jython and IronPython. — Paulo Scardine, Feb 28 '18 at 18:16
@PauloScardine yes, indeed. I would say one should worry about those things in CPython as well. — juanpa.arrivillaga, Feb 28 '18 at 18:18

Paulo Scardine · Accepted Answer · 2018-03-01T17:15:58.197

tl,dr; no

The reference implementation of Python uses reference counting for garbage collection. There are other implementations that use different GC strategies and this affects the precise time at which __del__ methods are called, which may or may not be reliable or timely in PyPy, Jython or IronPython. These differences are not important unless when you are dealing with resources like file pointers and other expensive system resources.

In cPython the GC will wipe out objects when the referencing count is zero. For example, when you do acumulator = mod.AcumulatorObject() inside a for loop, a new object replaces the old one at the next iteration - and since there are no other variables referencing the old object it will be garbage collected in the next GC pass. The reference implementation cPython will spoil you with things like releasing resources automatically when they go out of scope but YMMV regarding other implementations.

That is why many people commented memory leaks are not of concern in Python.

You have complete control over cPython's garbage collector using the cg module. The default settings are pretty conservative and in 10 years doing Python for a living I never had to fire a GC cycle manually - but I've seen a situation where delaying it helped performance:

Yes, I had previously played with sys.setcheckinterval. I changed it to 1000 (from its default of 100), but it didn't do any measurable difference. Disabling Garbage Collection has helped - thanks. This has been the biggest speedup so far - saving about 20% (171 minutes for the whole run, down to 135 minutes) - I'm not sure what the error bars are on that, but it must be a statistically significant increase.

Just follow best practices like wrapping system resources using with or (try/finally blocks) and you should have no problems.

Does this code create a memory leak in python?

1 Answers1