这取决于您所说的“更高效”是什么意思。
将变量设置为None
,假设它们是对其值的唯一引用,将允许垃圾收集器收集它们。在 CPython(它的垃圾收集器使用引用计数)中,它甚至会立即这样做。
但另一方面,您还向必须由解释器执行的函数添加了更多字节码,这使得代码对象更难保留在缓存中,等等。
请记住,释放内存几乎从来不意味着真正向操作系统释放内存。大多数 Python 实现都有多个级别的空闲列表,它通常位于类似的东西之上malloc
也是如此。因此,如果您打算分配足够的额外内存来增加峰值内存大小,那么在空闲列表上放置大量内容可能会阻止这种情况发生;如果你已经达到了巅峰,释放价值观不太可能产生任何影响。 (假设峰值内存使用量对您的应用程序很重要 - 仅仅因为它是迄今为止最容易测量的东西并不意味着它是与每个问题最相关的东西。)
在几乎所有现实生活中的代码中,这都不可能产生任何影响。如果确实如此,您将需要进行测试并了解内存压力和缓存位置等因素如何影响您的应用程序。你可能会让你的代码变得更好,你可能会让它变得更糟(至少假设某些特定的内存测量不是你关心优化的唯一事情),很可能你没有任何效果,但让它更长,因此更少可读。这是“过早优化是万恶之源”这句格言的完美例子。
如果我们在函数末尾执行此操作,答案会改变吗(因为我假设 python 本身会在此时执行此操作)?
你是对的,Python 在函数返回时释放局部变量。所以,是的,在这种情况下,你仍然会得到几乎所有的负面因素,而几乎没有任何正面因素,这可能会改变答案。
但是,抛开所有这些警告不谈,在某些情况下这可以改善情况。*因此,如果您分析了您的应用程序并发现保留该内存太久会导致真正的问题,请务必修复它!
不过,请注意del temp_1
将会产生与您正在寻找的相同的效果,并且您正在做什么以及为什么会更加明确。在大多数情况下,最好将代码重构为更小的函数,以便temp_1
一旦你处理完朋友,他们就会自然地超出范围,无需任何额外的工作。
* For example, imagine that the rest of the function is just an exact copy of the first half, with three new values. Having a perfect set of candidates at the top of the free lists is probably better than having to search the free lists more deeply—and definitely better than having to allocate more memory and possibly trigger swapping…