Python中遍历列表切片为何比遍历range()执行速度更快？

你的测试结果完全符合CPython的实现逻辑，核心差异来自Python字节码执行开销和C层面操作开销的巨大差距，具体可以拆解为3个关键点：

• 首先纠正一个认知误区：列表切片的拷贝开销远没有你想象的高。列表存储的是元素的引用（指针），切片时只会拷贝这部分指针，不会拷贝元素本身。64位系统下每个指针占8字节，哪怕是100万元素的切片，拷贝的总数据量也只有8MB，且整个拷贝过程是纯C实现的，执行效率极高，这点开销完全可以被后续迭代的收益覆盖。
• 列表遍历的迭代器是纯C实现的，全程没有Python字节码的额外开销。with_slice方法中for n in nums[sp:]的整个遍历过程都在C层面执行，不需要在Python层做任何额外操作。而no_slice方法每一轮循环都要执行两次Python字节码：先从range中拿到索引i，再通过nums[i]做下标查找取值，单轮循环的开销是C层面迭代的数倍，循环次数越多差距越明显。
• 即便是没有取值操作的pure_loop，小数据量下也比with_slice慢，是因为range迭代生成整数、校验边界的开销，还是高于直接遍历列表连续内存块的开销：列表底层是连续数组，CPU的缓存预取机制可以大幅提升连续读取的效率，而range迭代的逻辑相对更复杂。你也可以观察到当size到100万时，两者的耗时基本持平，这是因为此时切片拷贝的开销已经上涨到和range迭代的开销相当，如果继续增大列表长度，with_slice的耗时会逐渐超过pure_loop，此时切片拷贝的成本会超过迭代带来的收益。

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