为何Polars在文本解析场景下比Numpy慢？是否使用有误？

核心原因分析 #

1. 数据存储结构差异
   Numpy的(str,1)结构化数组是连续紧凑的字节存储，本质是把每个单字符直接存在连续内存块里，操作时可直接调用字节级指令，开销极低。而Polars的String类型为可变长度字符串设计，每个字符串会额外存储长度信息、编码标记，对于单字符这种极小单元，这些额外开销的占比会被无限放大。

2. 初始化方式的额外开销
   你从Numpy结构化字符数组转Polars DataFrame的过程中，Polars需要把每一列的单字符逐个转换为Polars的String对象——对于大数据量，这种逐元素的类型转换会产生巨量内存操作，直接导致初始化慢60倍。

3. 操作的底层实现差异
   Numpy的排序、筛选对于单字符数组可直接调用底层字节排序/比较逻辑，无额外字符串处理步骤；而Polars的字符串操作需要经过编码校验、长度判断等流程，在单字符场景下，这些流程的开销远大于实际操作本身。

修正使用误区的优化方案 #

1. 跳过Numpy中间层，直接构建Polars DataFrame

避免从Numpy结构化数组转换，直接从原始文本生成Polars的列，能大幅降低初始化开销：

import requests
import polars as pl

text = requests.get("https://files.rcsb.org/download/3w32.pdb").text
lines = text.splitlines()

# 直接生成每列的单字符序列
char_tab_pl = pl.DataFrame(
    {f"col_{i}": [line[i] if i < len(line) else "" for line in lines] for i in range(80)}
)

或者用更高效的批量转换：

import numpy as np
# 把每行转成固定80长度的字符数组，再转Polars
char_arr = np.array([list(line.ljust(80))[:80] for line in lines])
char_tab_pl = pl.from_records(char_arr, schema=[f"col_{i}" for i in range(80)])

2. 把单字符映射为整数类型

既然你测试过整数类型下Polars性能接近甚至超过Numpy，可把字符转成ASCII码整数，完全规避字符串操作的开销：

# 转换为整数列
char_tab_pl_int = char_tab_pl.with_columns(
    [pl.col(col).str.encode("ascii").arr.get(0).alias(col) for col in char_tab_pl.columns]
)

# 排序测试
char_tab_pl_int.sort(by="col_0")

# 筛选测试（筛选'A'对应ASCII码65）
char_tab_pl_int.filter(pl.col("col_0") == 65)

3. 大数据量场景用流式/批量加载

对于放大1000倍的文本，不要先把文本复制到内存再处理，而是用Polars的批量加载方式：

text_lines = text.splitlines()
big_lines = text_lines * 1000

# 用from_records直接加载二维字符数组，避免逐列转换
char_arr = np.array([list(line.ljust(80))[:80] for line in big_lines])
char_tab_pl = pl.from_records(char_arr, schema=[f"col_{i}" for i in range(80)])

这种方式的初始化时间会从2分钟大幅缩短到和Numpy接近的水平。

总结 #

Polars的优势在于大数据量下的多列复杂运算、内存高效的懒加载、并行处理，但对于单字符这种极小数据单元的场景，Numpy的紧凑内存结构天然更有优势。如果你的业务场景可以把字符映射为整数，Polars在大数据量多次查询的场景下会更划算；如果必须用字符串，优化初始化方式是提升性能的关键。

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