我有一个函数的三个实现来检查字符串（或空格分隔的短语）是否是回文：
def palindrome(str_in):
def p(s, i, j):
if i >= j:
return True
elif s[i] != s[j]:
return False
else:
return p(s, i+1, j-1)
return p(str_in.replace(' ', '').lower(), 0, len(str_in)-1)
def palindrome1(s):
st = s.replace(' ', '').lower()
return st == st[::-1]
def palindrome2(s):
st = s.replace(' ', '').lower()
i, j = 0, len(st)-1
while i < j:
if st[i] != st[j]:
return False
else:
i += 1
j -= 1
return True
现在，我认为palindrome()在理论上是最优的，因为没有发生反转和额外的内存，但是python没有尾调用优化。 palindrome2()是palindrome()的命令式版本，但仍需要比palindrome1()更长的时间。这是为什么？
以下是配置结果（与python -m cProfile file.py一起运行）：
12 function calls in 45.341 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.232 0.232 45.341 45.341 file.py:1(<module>)
1 2.198 2.198 3.532 3.532 file.py:300(palindrome1)
1 39.442 39.442 40.734 40.734 file.py:304(palindrome2)
1 0.000 0.000 0.000 0.000 {len}
1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects}
2 2.396 1.198 2.396 1.198 {method 'lower' of 'str' objects}
1 0.843 0.843 0.843 0.843 {method 'read' of 'file' objects}
2 0.231 0.115 0.231 0.115 {method 'replace' of 'str' objects}
1 0.000 0.000 0.000 0.000 {open}
1 0.000 0.000 0.000 0.000 {sys.setrecursionlimit}
以下是配置结果（与pypy -m cProfile hw2.py一起运行）：
11 function calls in 12.470 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.011 0.011 12.470 12.470 hw2.py:1(<module>)
1 2.594 2.594 6.280 6.280 hw2.py:303(palindrome1)
1 0.852 0.852 4.347 4.347 hw2.py:307(palindrome2)
1 0.000 0.000 0.000 0.000 {len}
1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects}
2 3.263 1.631 3.263 1.631 {method 'lower' of 'str' objects}
1 1.832 1.832 1.832 1.832 {method 'read' of 'file' objects}
2 3.918 1.959 3.918 1.959 {method 'replace' of 'str' objects}
1 0.000 0.000 0.000 0.000 {sys.setrecursionlimit}
这是我的回文构造函数：
def palindrome_maker(n):
from random import choice
alphabet = ' abcdefghijklmnopqrstuvwxyz'
front = ''.join([choice(alphabet) for _ in range(n//2)])
back = front[::-1]
return front + (choice(alphabet) if n%2==1 else '') + back
BTW：配置文件显示使用长度为999999999的字符串调用函数的性能。
答案 0 :(得分：1)
由于此开销，palindrome和palindrome2函数都比palindrome1慢。 CPython中有一个称为dis的简洁模块。如果在编译函数上使用它，它将显示其内部表示。所以我们这样做：
>>> dis.dis(palindrome)
2 0 LOAD_CLOSURE 0 (p)
3 BUILD_TUPLE 1
6 LOAD_CONST 1 (<code object p at 0x01B95110, file "<stdin>", line 2>)
9 LOAD_CONST 2 ('palindrome.<locals>.p')
12 MAKE_CLOSURE 0
15 STORE_DEREF 0 (p)
9 18 LOAD_DEREF 0 (p)
21 LOAD_FAST 0 (str_in)
24 LOAD_ATTR 0 (replace)
27 LOAD_CONST 3 (' ')
30 LOAD_CONST 4 ('')
33 CALL_FUNCTION 2 (2 positional, 0 keyword pair)
36 LOAD_ATTR 1 (lower)
39 CALL_FUNCTION 0 (0 positional, 0 keyword pair)
42 LOAD_CONST 5 (0)
45 LOAD_GLOBAL 2 (len)
48 LOAD_FAST 0 (str_in)
51 CALL_FUNCTION 1 (1 positional, 0 keyword pair)
54 LOAD_CONST 6 (1)
57 BINARY_SUBTRACT
58 CALL_FUNCTION 3 (3 positional, 0 keyword pair)
61 RETURN_VALUE
现在让我们将其与palindrome1函数进行比较：
>>> dis.dis(palindrome1)
2 0 LOAD_FAST 0 (s)
3 LOAD_ATTR 0 (replace)
6 LOAD_CONST 1 (' ')
9 LOAD_CONST 2 ('')
12 CALL_FUNCTION 2 (2 positional, 0 keyword pair)
15 LOAD_ATTR 1 (lower)
18 CALL_FUNCTION 0 (0 positional, 0 keyword pair)
21 STORE_FAST 1 (st)
3 24 LOAD_FAST 1 (st)
27 LOAD_FAST 1 (st)
30 LOAD_CONST 0 (None)
33 LOAD_CONST 0 (None)
36 LOAD_CONST 4 (-1)
39 BUILD_SLICE 3
42 BINARY_SUBSCR
43 COMPARE_OP 2 (==)
46 RETURN_VALUE
所以这就是CPython或多或少所看到的（实际上这些被编码成二进制形式，目前无关紧要）。然后虚拟机遍历这些行并逐个执行。
所以第一个显而易见的事情是：更多行==更多时间执行。这是因为必须解释每一行并且必须执行适当的C代码。由于循环和递归调用，除palindrome1以外的两个函数中都执行了很多行。所以基本上它就像你试图跑几圈，但Python说'不，不，不，你必须肩负20公斤跑＃34;得到的圈数越多（即执行的字节码越多），得到的速度越慢。通常这种性能下降在CPython中应该是线性的，但是真的谁知道没有阅读CPython的代码？我听说过一种名为inline caching的技术应该在CPython中实现，这会影响性能。我不知道是否已经完成。
其他的事情是Python中的调用很昂贵。如何在低级别进行调用（即将寄存器推入堆栈并跳转），有ABI。 C / C ++遵循它。现在Python确实不止于此。创建了一些框架（可以进行分析，例如发生异常时），进行最大递归检查等等。所有这些都会导致性能下降。
所以palindrome函数执行很多的调用。递归在Python中效率低下。特别是这就是palindrome2比palindrome1更快的原因。
另一件事是palindrome1有[::-1]转换为BUILD_SLICE调用，这是在C中实现的。所以即使它做了更多必要（没有理由创建另一个）字符串的副本）它仍然比其他函数更快，因为中间层（即字节码）是最小的。编译器不需要在字节码解释上浪费时间。
另一个重要的事情是，您在Python中创建的每个对象都必须进行垃圾回收。并且由于这些对象通常比纯C对象（例如由于引用计数器）更大，因此需要更多时间。啊，顺便说一下，递增和递减参考计数器也需要时间。还有一个名为GIL（全局解释器锁）的东西，它获取并释放每个命令的锁，以便字节码是线程安全的。即使单线程应用程序完全没有必要。但Python并不知道你在某些时候不会运行线程，每次都必须这样做。这一切都是为了让您不必担心大多数C / C ++程序员必须处理的难题。 ：）
现在PyPy是另一个故事。它里面有这个简洁的东西叫做JIT = Just In Time编译器。它需要什么才能使用任何Python字节码并将其转换为机器代码，然后重新使用。因此，对函数的初始调用具有此编译开销，但它仍然更快。最终，根本没有字节码，所有功能都完全在CPU上运行。然而，这并不意味着PyPy与用C编写的函数一样快（例如[::-1]）。仅仅因为在C级上进行了大量优化，我们不知道如何在PyPy或任何其他Python解释器中实现。这是由于语言的本质 - 它是动态的。现在是否真的不可能是另一个故事，它根本不明显，但目前我们还不知道如何做到这一点。
tl; dr; 内置函数（或更常见的是在Python中运行的C代码）始终至少与等效的纯Python代码一样快，并且在大多数情况下更快