序

距上一次升级 Beex 仅过去两个多月，又手欠了……

起因

我最初的构建逻辑是所有文章无序并行渲染，然后才给文章排序，最后渲染首页文章列表，大致如下：

这样性能最优，但同时也有一个问题，即每篇文章生成的时候并不知道自己的“上一篇”、“下一篇”是谁。

文章多了，尤其是写得比较长的时候，能自动在页尾加一个“下一篇”的链接还是比较方便浏览的，所以打算重构，变成这样：

经过

本来觉得没什么难度，结果之前执着于性能优化，很多地方都是“硬编码”的，预处理和渲染拆不开，自虐了好几天最后还是……把 src 文件夹往项目目录外面一挪，直接重写了。

因为以前“我觉得”抽象封装会拖慢性能，所以渲染直接写了几个大函数，处理逻辑全部堆在一起，为的是尽量减少传递变量的时候需要重新分配内存堆栈。但是这次体验到重写太麻烦了，于是把一些逻辑和对象抽象出来，封装成 struct，调用起来清晰又愉快，以后重构也容易些。就是多了一层抽象，“我觉得”整体的耗时会有毫秒级的损失吧。

结果

写完跑了一下，比之前速度还提升了 90% 接近翻倍了……编译器告诉我不要“我觉得”，要它觉得。

分析了一下原因，可能是因为使用了更快的排序方法，速度的提升远远大于抽象带来的性能损失，现在跑 170+ 个文件的耗时已经降到 1 秒以下了。

只出现了一个不是问题的问题：程序执行完显示的 files 数字比之前少，因为之前只要检查过的文件就会记录为已渲染，现在有些文件在“预处理”阶段就被丢弃了。

下载链接：Beex 下载

真理：

不要过早优化。

---

• 更新（2021-04-25）

发现了一个 bug，修复后速度又跌去了 50%，下次重构再优化吧。第二天速度又恢复了，可能当时 Windows 后台有任务。