On Wed, 8 Apr 2020 09:53:41 -0700 Guido van Rossum firstname.lastname@example.org wrote:
Look at the following code.
def foo(a, b): x = a + b if not x: return None sleep(1) # A calculation that does not use x return a*b
This code DECREFs x when the frame is exited (at the return statement). But (assuming) we can clearly see that x is not needed during the sleep (representing a big calculation), we could insert a "del x" statement before the sleep.
I think our compiler is smart enough to find out *some* cases where it could safely insert such del instructions. And this would potentially save some memory. (For example, in the above example, if a and b are large lists, x would be an even larger list, and its memory could be freed earlier.)
For sure, we could manually insert del statements in code where it matters to us. But if the compiler could do it in all code, regardless of whether it matters to us or not, it would probably catch some useful places where we wouldn't even have thought of this idea, and we might see a modest memory saving for most programs.
Can anyone tear this idea apart?
The problem is if variable `x` has a side-effect destructor. It's certainly not a common idiom to keep a resource alive simply by keeping a Python object around (you should probably use `with` instead), but I'm sure some people do it.
FWIW, Numba does something similar to try and release memory earlier. But Numba certainly doesn't claim to support general-purpose Python code :-)