pandas中df.drop(inplace=True)与df=df.drop()的区别及性能差异

日常做DataFrame列删除时常见的两种写法：

# 写法1：返回新对象后重新赋值
df = df.drop([columns], axis=1)
# 写法2：开启inplace原地修改
df.drop([columns], axis=1, inplace=True)

性能结论 #

常规场景下inplace=True的写法CPU、内存消耗都显著更低，二者的性能差距会随着DataFrame体量增大被放大，处理GB级以上数据时差异会非常明显。

底层逻辑说明 #

• 非inplace的赋值写法执行流程：
  pandas默认的drop逻辑是不可变对象风格，不开inplace参数时，会先把所有需要保留的列全量拷贝一份，生成一个全新的DataFrame对象，再把当前的df变量重新绑定到这个新对象上。原来的旧DataFrame不会立刻消失，要等到Python垃圾回收机制判定没有任何变量引用它时，才会被回收释放内存。
  这个流程的额外开销非常明确：CPU要承担整份数据拷贝的计算量，内存会在拷贝阶段出现峰值——此时内存里同时存在旧DataFrame和新DataFrame两份完整数据，峰值占用接近原数据内存的2倍。
• inplace=True的原地修改写法执行流程：
  开启inplace后，pandas不会生成全量的新DataFrame，而是直接操作原有DataFrame的底层BlockManager结构：只需要调整列索引的映射关系，把待删除列对应的内存块引用移除即可，不需要拷贝所有保留列的实际数据。
  这个过程的CPU开销只有少量索引结构调整的成本，几乎可以忽略；内存上也不会出现双份数据并存的峰值，仅需要消耗极少量存储新索引结构的内存，整体资源占用低很多。

补充说明 #

这里要提一个容易踩的坑：如果原来的df被其他变量引用过，inplace=True会直接修改所有引用指向的原始对象，很容易引发意料之外的逻辑错误。如果代码里存在多变量引用同一个DataFrame的场景，哪怕非inplace写法性能差一点，也更推荐用重新赋值的写法保证逻辑安全。pandas后续版本逐步降低inplace参数的推荐优先级，也完全是出于代码安全性的考虑，和性能表现无关。

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