Result
简单翻译下：就是经过一年的努力，mattsta 终于做出符合 Redis 匹配的 CRC-64 算法快速版本，而且作为额外奖励，也能用在CRC-16上噢，并且可以摒弃老版本源代码中一堆静态查找表。可以在需要的时候再动态生成，而不是总是拖着它们使代码膨胀。
我们来看看老版本的代码确实有一堆，我截了一小段。
也就是 mattsta 写的快速 CRC 实现版本-crcspeed，不仅速度更快，而且清减了代码。
然后 mattsta 来了一波不要相信我说的话，咱们来让数据说话（傲娇.jpg）。
通过 mattsta 自己的笔记本测出的 crcspeed 从耗时、吞吐量和每字节所需CPU周期三方面来看都优于 Redis 的实现。
Real-World Impact
mattsta 又指出 crcspeed 能给Redis 带来啥呢？
简单的翻译下就是：Redis 在生成 RDB 的时候会 fork 出子进程，因此采用的是写时复制，所以内存的增长取决于写入的负载，那么快速的结束 RDB 退出 fork 的子进程，用在 COW 的内存就会更少，而生成 RDB 的时候又用到了CRC-64 作为校验，那么 CRC-64 校验越快，RDB 生成的就越快，用于 COW 复制而使用的内存就越少。
并且
mattsta 说这是一个有效和高效的多方面的双赢！
我本以为文章都这里就差不多了，然而并没有。
Minor Notes
可以看出 mattsta 是不想造轮子的，但是实在是没有轮子啊！于是他只能自己实现一个，这是个新轮子！
Resources Consulted
然后他列出了他所参考的一些资源，他首先感谢了「A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS」这篇文章。
让我们学一下感谢参考资料的正确姿势。
有一说一，确实，纯路人。身为一个txt，编写良好、格式良好，有趣。在风格、布局和语气的所有方面都经过了专家的深思熟虑。
夸一番 mattsta 觉得还不够，还得加一点自己的想法。
简单的翻一下：在某种程度上，互联网已经失去了保存写的好的、格式良好的、信息丰富的指南以及常见问题的解答和平易近人的研究论文的能力。我们应该努力把那部分世界夺回来。这种损失该归咎于什么呢？对风格的过分依赖？CSS？还是 JavaScript？PHP？。
世界上最好的语言警告！
看到没，这才叫感谢。mattsta 追求纯干货，别给我整一些花里胡哨的！
而且这篇文章还让 mattsta 确信他没有能力实现一个 CRC-64 算法，因此实际上他是依靠 pycrc 来实现的。
然后这位老哥又说 yahyahyah，linux kernel 也是这样用的。
这老哥真的对我胃口哈哈哈。mattsta 的文章还没结束，下面写的是一些关于实现的细节。有兴趣的朋友到时候可以看看，文末会放链接。我就不再跟下去了。
我们再来看身为 Redis Contributor 为何 mattsta 会写这一篇文章？不应该提 pr 直接解决吗？难道这算法有什么致命之处使得 Antirez 不接受？我们来追踪一下！
追踪事情的来龙去脉
首先这篇文章写于2014-12-22
提出的 issue 没有受到团队成员的响应，寂寞如雪，只有一位金毛小哥，为其打 call。这个issue 此时还是 open 的。
然后在当年，2014-11-23，mattsta 创建了 crcspeed 库，并且提交了实现。
并在2014-12-22提交了pr，竟然和写文章是同一天！而且是先写了文章再提的 pr。一开始我以为是提了pr迟迟得不到采纳，然后才一怒之下写的文章。
可以看到隔了一天有团队人员回应了，他说我不知道这是否会被合并(我认为它应该) ，但是，该死的！这是一个伟大的提升！牛皮克拉斯！
2014-12-23，mattsta 又对 pr 做了一些补充说明。然而没有回应。
直到2015-01-10，mattsta 对 pr 又做了一波更新。
antirez 说，很有意思但是我想看到固定的大于 5% 收益的可重现的测试用例，即使是综合性的测试也没事，只要明显的能在 Redis 中反映出来即可，我相信从集群的 crc16 入手测试能很简单的证明效果，现在对于合并更快的实现不是很急，不过如果有一天你完成了这样的测试，我将会很感激。
然后给这个pr加了个标 review - and - merge。
还加了个ps: 通常来说证明一个东西的性能提升是很重要啊，我在这里做了个例外，因为我看它单独的测试确实快了很多，我相信即使 Redis 没有使用上这个经验，但是迟早我们也会受益于它
简单的说就是 mattsta 你得搞个 Redis 相关的测试来证明它真的使得 Redis 性能提升了啊，这样我才能合并啊，不过我做个例外，是认可你这个的，给你打个标！(但是没有真正的合并)。
也就是说 antirez 其实是认可 mattsta 的实现的，但是 mattsta 没有给出和 Redis 相关的测试，所以还不能合并这个 pr。
这个 pr 就到这里过了，再也没有更新，也还是 Open 的。
mattsta 也没有继续说啥，对 Redis 输出到2015年初之后就不再输出了。而 CRC-16 到现在还使用的是老版本，CRC-64 是 antirez 在时隔六年的2020-04-28做的修改，使用的就是 mattsta 的crcspeed。
再回头看
可以到 mattsta 在 2014-04-01就提了 issue，然后没有任何回应的情况下自己研究，找了许多资料，最后实现了 crcspeed，也肝出了一篇文章，之后在同一天提了PR，然后过了近两个月的时间得到 antirez 的回复，由其没有关于 Redis 的实质上的测试，因此不给合并，但被给予肯定。
但我个人猜测 mattsta 可能还是有点生气的，这么一个通用的东西，我都给了横向对比测试了！这原理我也分析的这么清楚了！这明摆着肯定是 ok 的，你还要我测试啥！不合并拉倒！(再次傲娇.jpg)。
而 antirez 所在的角度不一样，他是 Redis 的亲爸爸。你说的没错，我认可你，但是你得拿出实质性的证明给我看看你帮我的 Redis 提升了多少。
其实双方我都能理解，所处角色不同。最终我们终于得知整个事情的来龙去脉，再附上一直 mattsta 的靓照，看来发量不错。
这篇文章讲述的就是这么个事儿。其实我就是带着八卦之心来看为何身为 Contributor 的 mattsta 提的明显正确的 pr 没有被 merge，至于什么 CRC 的我不关心哈哈哈哈。
当然 mattsta 的钻研之心值得我们学习，当然还有他那搞笑的形容和五彩斑斓的感谢。而 antirez 对 pr 的严谨也值得我们效仿。
