@DIYgod: 一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差，今天 Cloudflare 回应了篇博客承认错误，解释了造成问题的各种技术细节，现在把性能也追上来了 太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了，现在倒是显得 Vercel 小肚鸡肠了...

AI 摘要：本文由 Cloudflare 首席架构师 Kenton Varda 撰写，针对独立开发者 Theo Browne 公布的基准测试结果展开调查与回应。原测试显示 Cloudflare Workers 在 CPU 密集型 JavaScript 任务中比 Vercel（基于 AWS Lambda）慢至 3.5 倍。Cloudflare 分析后发现，性能差异主要源自调度算法、V8 垃圾回收参数旧配置、OpenNext 框架实现低效及测试方法偏差。经过多项修复与调优，Workers 性能已与 Vercel 持平甚至超越。文中还披露了 Cloudflare 对 V8 与 Node.js 性能改进的贡献，证明其优化不仅服务自家平台，更惠及广泛的 JavaScript 生态。

1. 基准测试背景与问题调查
• 独立开发者 Theo Browne 公布测试，显示 Cloudflare Workers 明显落后 Vercel
• 两者皆基于相同的 V8 引擎，理论上应相近性能
• 性能差异达到 3.5 倍，引发 Cloudflare 团队深入分析
• 指出测试方法主要反映“等待时间”而非“实际 CPU 使用”

2. 平台调度算法与运行时优化
• Workers “warm isolate routing” 策略导致 CPU 密集型请求排队
• 调整调度算法，让系统更快检测并扩展新 isolate，避免阻塞
• 改进后大幅降低延迟波动，提高自动扩展效率

3. V8 (JavaScript 引擎) 垃圾回收 (Garbage Collector, GC) 调优
• 发现旧参数设定限制了“young generation”空间大小
• 放宽 GC 配置让 V8 自调内存区间，性能提升约 25%
• 改进已全球部署，影响所有 Workers

4. 优化 OpenNext 与 Next.js 性能
• 识别大量不必要的内存复制与 Buffer 分配
• 对流式响应 (Streaming) 做性能补丁，减少冗余数据操作
• 提交多个 PR 改进 OpenNext，包括缓存优化、流管道调度、正则重用等
• 针对 JSON.parse reviver 函数的低效执行向 V8 上游提交补丁，提升约 33% 性能

5. Streams 适配与数据传输改进
• Node.js 与 Web Streams API 转换时存在重复缓冲问题
• 改用原生 ReadableStream.from(chunks) 避免多层拷贝
• 调整 ReadableStream highWaterMark，使字节流读取更高效

6. Node.js 三角函数性能修复
• Node.js 未启用 V8 trig 函数快速路径
• Workers 已默认启用，因此跑分更好
• Cloudflare 提交 PR 修复 Node.js 构建配置，使全生态受益

7. 对基准测试方法的反思与改进
• 本地测试中网络延迟影响 CPU 计算评估
• Cloudflare 与 Vercel 所用硬件代际不同，会引入性能噪声
• Next.js 与 React SSR 测试中存在 force-dynamic 与 NODE_ENV 配置错误导致性能偏差
• 建议未来基准采用可控环境与更准确指标（TTLB 而非仅 TTFB）

8. 后续计划与开放协作
• 所有平台级修复已上线，无需用户手动更新
• 将继续优化 OpenNext 与 V8，推动上游框架改进
• Cloudflare 鼓励社区提交性能测试，团队会分析并修复问题
• 长期目标：通过改进开放源代码基础设施提升整个生态性能

FixupX

DIŸgöd ☀️ (@DIYgod)

一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差，今天 Cloudflare 回应了篇博客承认错误，解释了造成问题的各种技术细节，现在把性能也追上来了

太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了，现在倒是显得 Vercel 小肚鸡肠了...

AI 摘要：本文深入解析了 V8 JavaScript 引擎如何将人类可读的代码转换为机器码的全过程，重点介绍了 Ignition 解释器、字节码生成与执行机制，以及 TurboFan 的 JIT 优化技术。通过示例代码的字节码逐步分析，揭示了 V8 如何利用寄存器、反馈向量和对象形状（Shapes）实现高效执行，最终将高频调用的“热点”函数编译为机器码。

1. 脚本加载与解析
• 浏览器通过 HTML 解析器识别 <script> 标签并获取 JavaScript 文件字节流。
• 字节流解码器 将原始字节转换为标记（Tokens），例如识别 function 为关键字。

2. 语法分析与 AST 生成
• 解析器 将 Tokens 转换为抽象语法树（AST），同时检查语法错误。

3. Ignition 解释器与字节码执行
• Ignition 将 AST 编译为平台无关的字节码（介于人类代码与机器码间的抽象层）。
• 寄存器操作示例（以 calc 函数为例）：
• LdaSmi [10] 加载常量到累加器 → Star1 存入寄存器 r1
• GetNamedProperty a0,[0] 获取参数对象属性（如 obj.x ）→ 通过 Add 指令进行运算。
• 最终结果通过 Return 指令返回。

4. 优化技术（TurboFan JIT）
• 反馈向量（Feedback Vector）：记录运行时类型信息（如对象形状），用于触发优化。
• 对象形状（Shapes）：相同结构的对象（如 {x,y,z} ）共享形状，加速属性访问。
• JIT 编译：对高频调用的“热点”函数生成优化的机器码，若类型假设失效则回退至解释执行。

5. 关键概念
• 寄存器类型：通用寄存器（ r0-rn ）、参数寄存器（ a0-an ）、累加器（临时存储计算结果）。
• 字节码调试：通过 node --print-bytecode 查看生成的字节码。

AI 摘要：通过解析 V8 引擎的 JIT 编译机制，解释 JavaScript 如何通过动态优化热点代码实现百倍性能提升。

本文以 V8 引擎为例，深入探讨 JavaScript 的 JIT（即时编译）技术如何弥合解释型语言与编译型语言的性能差距。作者通过一个计算数组和的示例代码，详细拆解 JIT 的工作流程：
1. 解析与字节码生成：代码被转换为抽象语法树（AST）后生成中间字节码。
2. 热点代码识别：高频执行的代码（如循环）被标记为“热代码”，触发优化编译为机器码。
3. 动态优化与去优化：若运行时假设失效（如变量类型变化），引擎会回退到未优化状态并重新编译。
文章结合代码示例、AST 结构、字节码片段和优化逻辑，直观展示了 JIT 如何通过减少解释器开销和针对性优化显著提升性能，并强调其核心目标是平衡灵活性与执行效率。

AI 摘要：V8 通过引入可变堆数值（mutable heap numbers）和 Int32 类型追踪优化 Math.random 实现，使 async-fs 基准测试性能提升 2.5 倍。

# 文章内容
本文解析了 V8 团队针对 JetStream2 基准测试套件中 async-fs 性能问题的优化过程。该基准测试使用自定义的确定性 Math.random 实现，其核心变量 seed 存储于 ScriptContext 中。由于 seed 的每次更新都会触发新的 HeapNumber 对象分配，并伴随低效的浮点运算，导致显著的内存分配与垃圾回收压力。

V8 团队通过两项关键优化解决此问题：
1. 可变堆数值槽：扩展 ScriptContext 的槽类型追踪能力，允许直接修改 HeapNumber 的值而非重新分配
2. 可变 Int32 类型：追踪数值是否在 Int32 范围内，避免浮点转换开销

这些优化不仅使 async-fs 性能提升 2.5 倍，也为处理类似模式的真实场景代码提供了通用优化方案。