pandas 1.2.1中先构建列表再生成DataFrame为何比逐行append耗时更长？

1. 第二种实现存在关键逻辑错误 #

• pandas 1.2.1 中DataFrame.append()为非原地操作：执行后会返回一个全新的DataFrame，不会修改调用该方法的原对象，pandas 2.0之后已正式废弃该方法，核心原因就是这类非原地特性极易引发逻辑错误。
• 现有第二种逻辑仅调用x.append(...)，未将返回值赋值回x，循环执行完成后x始终是初始化的空DataFrame，所有append调用都没有产生实际的内存写入、数据对齐、类型推断等开销，完全跳过了DataFrame构建的核心逻辑。
• 第一种实现是真实完成了全量DataFrame的构建，后者相当于没有执行这部分工作，耗时自然更短。

2. 测试耗时的核心来源并非DataFrame操作 #

• 整个测试的时间几乎全部消耗在30次雅虎财经API的网络请求上，这部分耗时占总时长的99%以上。
• 公开benchmark中“先攒列表再一次性生成DataFrame性能更优”的结论，针对的是纯内存计算场景：即所有数据已经收集完成，仅对比两种DataFrame构建方式的纯计算开销。
• 在本场景下，DataFrame构建的耗时和网络请求耗时相比几乎可以忽略，原本的性能差异完全被网络请求的耗时掩盖。

3. 额外的实现差异放大了结果偏差 #

• 第一种实现构建DataFrame时，直接用sp500_df["Ticker"].tolist()[:30]匹配三个列表，若循环中出现API请求失败触发continue，会导致ticker列表长度大于prices/marketcaps列表，触发隐式的数据对齐校验开销。
• 若修正第二种实现的赋值bug，将代码改为x = x.append({...}, ignore_index=True)，实际耗时会大幅上升，甚至超过第一种实现的总耗时，完全符合公开benchmark的结论。

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