#performance-optimization

一篇性能导向的工程文章展示了评论中称为 Earstrip 的三角剖分库：作者称其在约 370 万个地图多边形组成的语料上完成剖分仅用 489 毫秒，快于广泛使用的 earcut。文章公开了数据集，earcut 作者也参与了技术讨论；这仍是作者自测的基准，尚非独立复现的通用结论。对处理大规模 GIS 或图形几何的开发者，这一结果值得用自己的数据复测，并同时考察包体积与输出三角形质量。

rss · Sean Goedecke · 10月23日 00:00 「背景」 近来不少人期待让 AI 把软件重写成 C 或 Rust 来大幅提速。Sean Goedecke 认为这条路通常走不通：C 也许比 Python 快五十倍，但重写并不会带来五十倍加速。 「方案」 他的核心论据是，真实程序多为 I/O 密集型——一次 CRUD 请求可能有约一半时间花在数据库查询上，重写只能作用于剩余部分（即 Amdahl 定律），实际大概只有 1.5 倍提升。即便是明显的 CPU 密集工作，慢语言也往往已通过 cmark-gfm、NumPy 与 GPU 这类库把计算交给高度优化的 C 或汇编；tiktoken 的汇编重写虽在作者笔记本上约快 5 倍，但作者认为这更多来自去掉正则依赖的重设计，且分词只占推理时间的一小部分。Bryan Cantrill 曾试图把一段精心优化的 C 程序直译为 Rust，因借用检查器受阻后改用朴素写法，结果反而快 30%，原因是 Rust 默认的 B 树比二叉搜索树更缓存友好——即便在 CPU 密集场景，设计也压过语言。作者自己经历的显著提速几乎都来自让程序少做工作：缓存慢调用、把慢操作异步化或移出请求周期、并行化、合并 N+1 查询、换掉慢 SQL、跳过不必要的取数；而高级语言反而更容易一眼看出这些机会。 「启示」 因此，语言重写并不是严肃的优化手段；更有效的做法是让 AI 去剖析性能热点并重设计程序，只有在罕见的、无法再减少工作量的 CPU 热点上，才值得局部改写。 标签: performance-optimization, software-design, amdahls-law, profiling, io-bound