Question

这是一个优化问题。我在以下函数中有一个表达式：

>>> def x():
...     num = 2 * 4 * 100 * 20
...
>>> x.__code__.co_consts
(None, 2, 4, 100, 20, 8, 800, 16000)

表达式2 * 4 * 100 * 20的结果是16000，所以如果我们反汇编x：

>>> dis.dis(x)
  2           0 LOAD_CONST               7 (16000)
              3 STORE_FAST               0 (x)
              6 LOAD_CONST               0 (None)
              9 RETURN_VALUE

16000几乎是需要的。 co_consts存储8和800，技术上不再需要我们有总数还是它们？

将上述表达式与另一表达式进行比较：

>>> def x():
...     num = 3 + 4 + 9  * 4
... 
>>> x.__code__.co_consts
(None, 3, 4, 9, 7, 36)

看起来字节码编译器采用二进制操作数并存储它们的计算值：

9 * 4   36 
3 + 4   7

反汇编功能：

>>> dis.dis(x)
  2           0 LOAD_CONST               4 (7)
              3 LOAD_CONST               5 (36)
              6 BINARY_ADD          
              7 STORE_FAST               0 (num)
             10 LOAD_CONST               0 (None)
             13 RETURN_VALUE

有趣的是，如果你使用这个表达式：2 + 5 * 8 - 5 + 23 * 4，co_consts将仅(None, 2, 5, 8, 23, 4, 40, 92)计算乘法：5 * 8和23 * 4加法和减法被忽略了。

这种优化如何真正起作用？我只在2.7测试过这个。

Answer 1

没有解释这个;-)这意味着它是一个完全反映实现细节的黑暗角落。无论好坏，＆＃34;窥视孔优化器＆＃34;负责的工作不在程序的解析树上，而是在生成的字节代码上。使用起来很笨拙，因此很难预测将会发生什么，并且它会在各个版本中发生变化。例如，在Python 3.6.1下：

>>> def f():
...     return 2 + 5 * 8 - 5 + 23 * 4
>>> f.__code__.co_consts
(None, 2, 5, 8, 23, 4, 40, 42, 37, 92, 129)
>>> import dis
>>> dis.dis(f)
  2           0 LOAD_CONST              10 (129)
              2 RETURN_VALUE

因此表达式已折叠为其最终值，但所有中间值都留在常量元组中。

@COLDSPEED已经在他们的评论中链接到了源代码，并且任何有关它的问题的唯一真正答案都来自于盯着您正在运行的CPython版本中使用的peephole.c。随着时间的推移，它逐渐变得更加雄心勃勃，但背后并没有真正的计划。

这个内部Python优化如何适用于数学表达式？

1 个答案: