s=s c字符串conat优化是如何决定的？

Question

简短版本：如果s是一个字符串，那么s=s“c”可能会在适当的位置修改字符串，而t=s“c”不能。但是操作如何知道它在哪种情况下？

长版本：

t=s“c”需要创建一个单独的字符串，因为程序随后希望旧字符串为s，新字符串为t。

如果s是唯一的参考，则s=s“c”可以修改字符串，因为程序只希望s是扩展字符串。如果末尾有多余的字符空间，CPython实际上会进行这种优化。

考虑这些函数，它们重复添加一个字符：

def fast(n):
    s = ''
    for _ in range(n):
        s = s + 'c'
        t = s
        del t

def slow(n):
    s = ''
    for _ in range(n):
        t = s + 'c'
        s = t
        del t

使用n=100_000对结果进行基准测试（在线尝试！）：

fast :   9 ms    9 ms    9 ms    9 ms   10 ms 
slow : 924 ms  927 ms  931 ms  933 ms  945 ms

请注意，额外的t=s或s=t使这两个变量都等效于字符串的引用，然后del t只剩下s，因此在下一次循环迭代中，s再次是字符串的唯一引用。因此，这两个函数之间的唯一区别是分配给s和t的顺序。

我们还要反汇编字节码。我用标记了仅有的三个差异= 在中间。正如预期的那样，只有STORE\u FAST和LOAD\u FAST的变量不同。但是，直到并包括BINARY\u ADD，字节码是相同的。那么，BINARY\u ADD如何知道是否要优化呢？

      import dis                                 import dis
      dis.dis(fast)                              dis.dis(slow)
---------------------------------------------------------------------------
    0 LOAD_CONST     1 ('')                    0 LOAD_CONST     1 ('')
    2 STORE_FAST     1 (s)                     2 STORE_FAST     1 (s)
                                                                 
    4 LOAD_GLOBAL    0 (range)                 4 LOAD_GLOBAL    0 (range)
    6 LOAD_FAST      0 (n)                     6 LOAD_FAST      0 (n)
    8 CALL_FUNCTION  1                         8 CALL_FUNCTION  1
   10 GET_ITER                                10 GET_ITER      
>> 12 FOR_ITER      18 (to 32)             >> 12 FOR_ITER      18 (to 32)
   14 STORE_FAST     2 (_)                    14 STORE_FAST     2 (_)
                                                               
   16 LOAD_FAST      1 (s)                    16 LOAD_FAST      1 (s)
   18 LOAD_CONST     2 ('c')                  18 LOAD_CONST     2 ('c')
   20 BINARY_ADD                              20 BINARY_ADD    
   22 STORE_FAST     1 (s)        !=          22 STORE_FAST     3 (t)
                                                               
   24 LOAD_FAST      1 (s)        !=          24 LOAD_FAST      3 (t)
   26 STORE_FAST     3 (t)        !=          26 STORE_FAST     1 (s)
                                                               
   28 DELETE_FAST    3 (t)                    28 DELETE_FAST    3 (t)
   30 JUMP_ABSOLUTE 12                        30 JUMP_ABSOLUTE 12
>> 32 LOAD_CONST     0 (None)              >> 32 LOAD_CONST     0 (None)
   34 RETURN_VALUE                            34 RETURN_VALUE  




Answer 1

下面是有问题的代码，来自Python 3.10分支（在ceval.c中，并从同一文件的二进制添加操作码实现中调用）。正如@jasonharper在一篇评论中所指出的，它会向前看，看看二进制加法的结果是否会被绑定到左手加数所在的名称上。在快速（code）中，它是（操作数来自s，结果存储到s中），但在慢速（code）中它不是（操作数来自s，但存储到t中）。

不过，不能保证这种优化会持续下去。例如，我注意到您的fast（）并不比当前开发的CPythonmain分支上的slow（）快（这是目前正在进行的最终3.11版本的工作）。

如前所述，不能保证这种优化会持续下去。“严肃的”Python程序员应该知道不要依赖不可靠的CPython特定技巧，事实上，PEP 8明确警告不要依赖这个特定的技巧：

代码的编写方式应不影响其他Python实现（PyPy、Jython、IronPython、Cython、Psyco等）。

例如，不要依赖CPython对a=b或a=a b形式的语句的就地字符串连接的有效实现...