性能差异在这里很重要。
但是这些是非常不同的界面,做不同的事情,几乎可以肯定会很重要。
所以,这就是你应该如何决定写哪一个:你想问一个圆的周长,还是你想问一个圆来计算一个完全不同的圆的周长?
但如果您确实关心性能,那么获得答案的唯一方法就是对其进行测试。 Python 附带了一个timeit 模块,专门用于对此类代码的 sn-ps 进行基准测试。如果你使用 IPython/Jupyter,它有一个更好的包装器,称为%timeit。
下面是 %timeit 在我的机器上所说的,运行 64 位 python.org CPython 3.7,带有您的示例数据:
In [417]: %timeit nc.get_circum_self()
323 ns ± 10.7 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
In [418]: %timeit nc.get_circum_pi(111, 1)
258 ns ± 6.55 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
这是有道理的。只是传递整数并不是完全免费的(它们必须从堆栈中推送和弹出,并且在 CPython 中,它们的引用计数必须被调整),但它非常快。最重要的是,按名称查找对象中的属性需要做更多的工作。显然,这大约是 70 纳秒的额外工作。
但请考虑如何以更实际的方式使用它。如果您只想在源代码中使用硬编码值计算一个圆周,那显然只会发生一次,那么谁在乎它是 323ns 还是 258ns?如果你想计算它们的无数个,这些值可能来自某个变量,对吧?所以,让我们比较一下:
In [419]: pi, rad = 111, 1
In [420]: %timeit nc.get_circum_pi(pi, rad)
319 ns ± 15.19 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
看起来查找一对全局变量与查找一对属性一样昂贵。再一次,这并不太令人惊讶——无论哪种方式,我们都在一个名称空间中查找一个名称(一个字符串,其哈希值在我们到达这里之前已经被预先计算过)(这对于全局变量来说都是一个普通的旧字典)对于像你写的那样的普通课程),所以它的工作量大致相同。
同样值得注意的是get_circum_pi 对self 没有任何作用,而且根本没有理由成为一种方法。所以,如果你真的想挤出最后几纳秒,为什么要强迫自己将方法作为一个属性来查找呢?为什么不把它变成一个函数呢?
In [423]: def get_circum_pi(pi, radius):
...: return pi * radius * 2
In [424]: %timeit get_circum_pi(111, 1)
180 ns ± 4.54 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
这为我们节省了更多时间。同样,这是有道理的,但前提是您对方法的工作原理有更多了解。查找方法需要查找函数,而不是在对象自己的字典中查找,退回到类的字典中,然后在函数上调用描述符__get__ 将其绑定为方法。这是一大堆工作。
嗯,这是 78 纳秒的工作,但仍然不是很多。
值得了解所有这些事情的作用,它们需要多长时间,以及替代方案是什么。例如,如果您正在计算无数周长,您可以将绑定方法存储在一个变量中,而不是一遍又一遍地查找它。您可以在函数内移动整个循环,因此绑定的方法和全局变量都成为局部变量(这有点快)。等等。
几乎不值得做这些事情——但“很少”不是“从不”。对于现实生活中的示例,请参阅 recipes in the itertools docs 中的 unique_everseen 函数——seen_add = seen.add 之所以存在,是因为事实证明它确实在使用此配方的一些现实生活中的程序中产生了影响。