一个刚发布0.2.0版本、由个人维护的C++20压缩库,在自己的基准测试里把LZ4的单线程解压速度甩开1.5到3倍,压缩率还经常更好。这个数字足够扎眼,但压缩库这种东西,历来是“跑分容易,可信难”。misa77瞄准的是一个很窄但很真实的场景——写一次,读很多次——为此它愿意付出几乎所有主流压缩库都不愿付出的代价:压缩慢得离谱,没有熵编码后端,格式还在变,解码器目前默认你给的输入是合法的。
跑分亮点:解压快在哪,快多少
作者的测试台是一颗Intel i7-14650HX,单核绑定性能核、关闭Turbo、CPU调度器设为performance,用lzbench的公开分支跑分。这是一套干净但典型的“理想条件”自测,还没有独立第三方复现。
| 项目 | misa77-0 | misa77-1 | LZ4 |
|---|---|---|---|
| Silesia解压速度 | 5219 MB/s | 4274 MB/s | 2505 MB/s |
| Silesia压缩率 | 42.64% | 39.65% | 47.59% |
| enwik8解压速度 | 4802 MB/s | 4134 MB/s | 2355 MB/s |
| enwik8压缩率 | 48.59% | 44.05% | 57.26% |
（表中百分比越低代表压得越小,ratio数字是压缩后大小占比。）
数字背后有个反常点:压缩率越高的文件,misa77解压反而越快,这是它刻意设计的“协同效应”。作者甚至专门做了几种实验压缩模式,牺牲更多压缩时间去换一个更利于CPU微架构解码的字节流。这也解释了为什么它比LZ4慢十倍以上的压缩速度(约50MB/s对LZ4的371MB/s),在这个项目里是被主动接受的代价,而不是缺陷。
适用边界:写一次读多次,谁真正受益
misa77的性能不是均匀分布的,是“尖刺状”的,跟数据形态强相关。在Silesia语料里12个文件中,level 0在全部文件上都比LZ4解压快,但x-ray这类接近不可压缩的数据是明显例外——LZ4在这种文件上ratio接近1.0,基本退化成memcpy,misa77的优势被大幅削平。
- 结论.真正受益的是存储归档、静态资产分发、CDN冷数据、数据库列存这类写一次、读无数次的场景,压缩耗时可以摊销,解压吞吐才是瓶颈。
- 风险.如果数据本身就接近随机(已加密、已压缩、图像/音视频容器),misa77不会比LZ4快多少,甚至没有优势。
作者自己也承认,跨平台(x86/ARM)的对比数据来自v0.1.0,大概率已经过时,当前README给出的“帕累托前沿”说法,是项目自述,不是行业共识。
我的判断:性能工程亮眼,生产信用还没补齐
磨刀不误砍柴工——压缩慢一点,换解压快几倍,这笔账在写一次读多次的场景里完全划算,misa77在这条路上做得干净利落,基准数字也确实好看。这不是虚火,是实打实的性能工程活儿。
但值得较真的地方也在这里:0.2.0仍是v0.x版本,格式可能还会变;解码器默认输入合法,遇到畸形或恶意构造的压缩流是未定义行为;经过本地fuzzing,但作者自己写明“未加固”。安全可控的解码器要等到v0.3.0。
性能已经跑赢基准,信任还没跑到及格线。
对存储、CDN、数据分发这类系统的工程师来说,这意味着misa77目前只适合处理自己生成、自己信任的数据——严格意义上的写一次读多次内部管道,不适合直接吞吐来自外部、不可信的输入。用一个实验性项目去扛生产环境的不可信数据流,是把性能优势换成了安全风险,这笔账在生产系统里通常划不来。
真正决定misa77能不能从一个亮眼的跑分项目走到被工程团队采用的,不是它在哪张表里赢了LZ4多少,而是安全解码器什么时候落地、格式什么时候稳定下来、有没有人在生产环境里真正跑过它。这几件事,现在都还没有答案。