Python arrow vs pandas 的内存对比

pandas datetime64[ns] 内存更省，每元素仅8字节；arrow.arrow实例约64+字节，100万条可多占40mb以上，且无共享结构、gc压力大。

arrow 读取时间数据时内存不省，反而更高

用 arrow 解析字符串为时间对象，看起来轻量，但实际它底层仍会构造完整 datetime 对象（或带时区的 Arrow 实例），每个实例都有固定开销。而 pandas 的 Series[datetime64[ns]] 是紧凑的 numpy 数组，内存按字节对齐，批量存储效率高得多。

常见错误现象：arrow.Arrow 列表存 100 万条时间，内存占用常是 pandas.Series 的 3–5 倍；用 list(map(arrow.get, str_list)) 更是灾难——每条都新建对象、无共享结构。

• 使用场景：仅需单次解析、少量时间计算？arrow 没问题；批量处理、进 DataFrame、做时间序列分析？直接上 pandas.to_datetime()
• pandas.to_datetime() 默认启用 cache=True，重复字符串自动复用解析结果，arrow.get() 每次都重新 parse
• 若必须用 arrow（比如依赖其 shift() 或时区链式操作），先转成 datetime 再喂给 pandas：pd.Series([a.datetime for a in arrow_list])，别留着 Arrow 实例数组

pandas datetime64[ns] 的内存是固定的 8 字节/元素

datetime64[ns] 是 NumPy 的原生 dtype，底层就是 int64，每个值只占 8 字节，和 python 的 datetime（约 48 字节）或 arrow.Arrow（约 64+ 字节）完全不在一个量级。

性能影响：100 万条时间，datetime64[ns] 占约 7.6 MB；同数量的 list[Arrow] 很容易破 50 MB——不仅吃内存，GC 压力也大。

立即学习“Python免费学习笔记（深入）”；

• 参数差异：pandas.to_datetime(..., infer_datetime_format=True) 能跳过正则推断，比默认快 2–3 倍；arrow.get() 没等效优化开关
• 兼容性注意：datetime64[ns] 不能表示纳秒以上精度，也不能存时区信息（得用 datetime64[ns, tz]，内存翻倍）；arrow 天然支持任意时区链式转换，但代价是对象膨胀
• 路径陷阱：从 CSV 读时间别用 dtype={'time': 'String'} 再手动转——先让 pd.read_csv(..., parse_dates=['time']) 直接走 C parser，内存和速度双优

arrow 不适合当 pandas 时间列的底层存储

有人试过用 pd.Series 存 Arrow 对象，以为能兼顾易用性和灵活性。结果既没获得 datetime64 的内存优势，又丢掉了 Arrow 的方法链能力（因为 Series 不代理 Arrow 方法），还触发频繁的 __getattr__ 回退，性能反降。

错误现象：series.dt.hour 报 AttributeError；调 series.apply(Lambda x: x.shift(hours=1)) 比纯 pandas 慢一个数量级。

• 正确做法：时间运算全交给 pandas 的 .dt 访问器；真需要 arrow.shift() 那种语义，先转成 datetime，用 pd.Timedelta 或 pd.offsets 替代
• 配置项注意：pandas.options.mode.use_inf_as_na = True 不影响 datetime64 列的 NaT 行为，但会让 Arrow 的 None 处理更混乱——别混用
• 命令验证内存：用 series.memory_usage(deep=True).sum() 看真实占用，别信 sys.getsizeof(series) ——它不统计底层 NumPy 数据

事情说清了就结束。真正压内存的从来不是“选哪个库”，而是“有没有让时间数据落在连续的、无封装的数组里”。arrow 是个好工具，但它不是数组。