是否让 python 更紧凑，使其更高效？答案

【问题标题】：Does making python more compact, make it more efficient?是否让 python 更紧凑，使其更高效？
【发布时间】：2020-10-10 05:12:01
【问题描述】：

忽略代码可读性，是否值得删除冗余变量？

例如。转换此代码：

seconds = (milisec / 1000) % 60
minutes = milisec // (1000 * 60)
name = "{:>3}-{:0>5.2f}".format(minutes, seconds)

进入：

name = "{:>3}-{:0>5.2f}".format(
    milisec // (1000 * 60), # minutes
    (milisec / 1000) % 60,  # seconds
    )

【问题讨论】：

我几乎看不出这两种方法有什么区别。方法 1 只是稍微干净一些，确实如此，
“忽略代码可读性” - 或者，听我说，我们不这样做怎么样？
赋值给一个变量是一个字节码指令，而引用它是另一个......所以一个非常边缘，实际上不相关的区别。在这种代码中？毫无疑问，不值得。如果您在该级别进行微优化，CPython 可能是错误的工具。
请注意第一个表单不需要 cmets 告诉您它在做什么？这是更好的代码的标志。
选择您的第一个选项 - 但对于这两个选项，如果 milisec 应该是毫秒计数，它可能应该是 millisec。除非这段代码会被执行无数次，否则我确信在解决方案的设计和实现中还有更重要的事情需要担心。

标签： python python-3.x performance readability redundancy

【解决方案1】：

创建变量会在内存中占一点位置，因此如果不这样做会更快。不过，差别真的很小。

【讨论】：

需要有一个带有闪烁霓虹灯的巨大标签，说明虽然严格来说，变量的创建和实例化不如不这样做的选项，但区别完全是几乎可以忽略不计，几乎在任何基准测试系统上都处于误差范围内，甚至不值得考虑，除了对速度/内存效率要求的绝对最高要求。

【解决方案2】：

是的，你的第二段代码，正如你所说的更紧凑，将稍微更有效，因为分配给变量对应于一些机器指令。

from timeit import timeit

def function():

    milisec = 173000

    seconds = (milisec / 1000) % 60
    minutes = milisec // (1000 * 60)
    name = "{:>3}-{:0>5.2f}".format(minutes, seconds)


print(timeit(stmt='function()', setup='from __main__ import function', ))



def function2():
    milisec = 173000
    name = "{:>3}-{:0>5.2f}".format(
    milisec // (1000 * 60), # minutes
    (milisec / 1000) % 60,  # seconds
    )

print(timeit(stmt='function2()', setup='from __main__ import function2', ))

查看一批批次的一些差异（以秒为单位）

【讨论】：

此基准测试不仅测试代码的相关部分（例如，milisec = 173000 与正在测试的代码无关，应将其删除）并且不包含其他相关信息到使结果有意义的基准。例如，每个函数运行了多少次迭代？每次迭代的平均运行时间和标准差是多少？基准测试运行了多少次？
为了回答您的问题，您可能认为在两个测试中实例化变量会相等，但您要测试的是 十亿分之一 的操作差异一秒钟或更短的时间。假设您甚至可以找到该规模的实际差异，那么这样做需要您从基准测试中消除尽可能多的多余操作。任意数据点都是噪声，噪声会扭曲结果，然后当您的实际数据与噪声的幅度相同时，您最终会没有任何可用的数据。你不需要“博士”来理解基本的统计数据，伙计。
您发布了您的结果，我说您如何制作和展示这些结果缺乏透明度和严谨性，这使您的结论具有误导性和不可靠。您可以轻松地调整您的代码并包含相关信息（timeit 默认提供），它会解决所有问题。相反，您决定为此争论并声称我在“抨击您”。 StackOverflow 的存在是为了提供高质量的答案。你的回答质量不是很好，我告诉你确切的原因。你为什么这么个人化？
换句话说，将您的答案与最佳答案进行比较。他们使用了与您完全相同的方法，但他们只测试了需要测试的代码，并以非常透明和专业的方式展示了他们的发现。让你的答案质量与他们相匹配所需的努力是微不足道的。接管 umbridge 是一件非常愚蠢的事情。
是的，你是对的。如果您发现我的回答不够严谨，我接受您发表评论并更正我的回答。我只是发现你的反应有点不成比例，但这只是个人的解释。让我们在这里关闭它。总是做得越来越准确总比做得少好。

【解决方案3】：

就执行时间而言，compact 代码比 long 代码快 slighlty。快速评估可能是这样的：

话虽如此，代码的可读性很重要。它是 Python 代码的里程碑之一。调试、维护、团队合作（仅举几例）利用更好的代码可读性。

【讨论】：

值得注意的是，即使经过 1000 万次迭代，这两种方法的运行也在彼此的标准差之内或非常接近，这意味着哪种方法运行得更快很可能取决于程序员之外的其他方面控制。即使忽略这一点，操作之间的差异也只有 半纳秒。 这正是微优化的定义，应该_never_优先于代码可读性.