On Wed, 8 Apr 2020 09:53:41 -0700 Guido van Rossum <gu...@python.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 :-) Regards Antoine. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FRGMBNJ4CULCW6VWKMV43WU4SQWVLFM2/ Code of Conduct: http://python.org/psf/codeofconduct/
