std::cin >> word这个io可能比较慢确实，我改成
std::getline(std::cin, word)后，就由 28 秒 → 25 秒了。你可以自行统计一下分段用时，看看输入、计算和输出各占比多少。
我简单测了测，读取 1 亿 15 长度字符串用时。
std::cin >> word：5.1 秒std::getline(std::cin, word)：2.2 秒- 手动开 64KB 缓冲区，每次
std::cin.read()填充，std::memchr找\n，str.append()构造：1.4 秒感觉输入上，这速度也可以了。
而且，我
strace了一下 DuckDB，它也是要读到缓冲区里的，且缓冲区贼大，32MB。。且一定要填充完整 32MB，才干活。。怪不得我说，一边解压大文本/脚本实时生成内容，一边喂给 DuckDB，怎么耗时会变长。。明明 writer 产生内容的速度还挺快的呀。。
也许输入输出是大头（因为stdio是同步锁定的）
我取消与 stdio 同步了：
std::ios::sync_with_stdio(false);。这个确实很耗时间。不取消的话，总时间直接翻倍。。
把文件mmap到内存然后使用
char*指针直接访问如果想解压大文本，再通过管道喂给程序时，好像不能 mmap 了吧。。
可喜可贺，奇怪的姿势增加了
恭喜老虎喜提华为Pura 70 Pro+一部。
一加ace2Pro(灰|24+1024)
@老虎会游泳，
DuckDB也设成单线程的了。对比起来应该算公平的？
DuckDB双线程时 14 秒，3+线程爆（笔记本 8GB 板载）内存了。。老虎看这代码，有啥不合理的地方，才拖累性能，打不过
DuckDB吗？
老虎会游泳
