为什么Python中'in'运算符比多个'=='链式比较执行速度更快？

这一差异和逻辑层面的比较次数无关，本质是Python解释器执行两种写法的底层开销不同，核心原因有两点：

• 连续or判断存在大量冗余开销
  你写的 s[i] == 'a' or s[i] == 'e' or s[i] == 'i' or s[i] == 'o' or s[i] == 'u' 写法中，每一次比较都会重新执行一次s[i]下标取值操作。Python作为解释型语言，默认不会做公共子表达式的自动优化，每出现一次s[i]就会真的执行一次从字符串中取下标对应字符的操作，5次比较就会重复5次取值流程，再加上多次比较、跳转的字节码解释开销，累计下来冗余成本很高。
  你可以通过dis模块打印两种写法的字节码验证这一点：连续or的写法会重复生成多组BINARY_SUBSCR（取下标元素）、COMPARE_OP（等值比较）、JUMP_IF_TRUE_OR_POP（条件跳转）指令，冗余指令占比极高。
• in列表查询的底层是C实现的原生操作
  哪怕逻辑上in对长度为5的元音列表也要做最多5次等值比较，但整个遍历、比较的流程都是在Python底层的C语言层面执行，不需要走Python字节码的逐行解释开销，执行效率远高于Python层面的多分支判断。
  如果要进一步优化性能，可以把预定义的元音容器改成集合vowels = {'a','e','i','o','u'}，集合的in操作是O(1)复杂度的哈希查找，连遍历步骤都可以省略，速度会比列表查询还要快2~3倍。

如果想要手动or的写法性能接近in，可以先把待判断的字符赋值给临时变量，比如c = s[i]; if c == 'a' or c == 'e'...，这样可以避免重复取值的开销，但因为还是走Python字节码解释，速度仍然会略低于C实现的in操作。

内容的提问来源于stack exchange，提问作者user9499285