云端省寄送，本地省启动时间

Bun 下个版本要给启动速度再拧一把：为字节码启用 profile-guided optimization（PGO），启动时间最多快 2 倍——对应的开关已经给出：bun build --compile --bytecode --bytecode-order=./file。（演示见原贴）

这条小更新值得放在"运行效率"那篇（DHH 说 Coding 已不贵、Running 才是）之后读，因为它正是那句话的微观实证。启动时间是 Running 账本上最不起眼的一项——每次运行都要付、每次都不多——但恰恰是这类"每次都付一点点"的支出，乘上每天成千上万次启动，就成了体感上"这东西怎么这么慢"的元凶。

PGO 的思路也朴素得老派：用真实的运行画像去重排字节码，让热点先走——不改一行业务代码，只把已有的运行规律榨出来变成布局优势。

它还顺手展示了编译期优化与 AI 时代工具的互补关系。今晚聊的降本方法论多数发生在"发给模型什么"这一侧（前缀、工具、上下文）；这条发生在"本地跑什么"这一侧——两边合起来才是完整的效率版图：云端省寄送、本地省启动。当 agent 每天要拉起成百上千个短命进程（跑测试、起服务、执行脚本），启动就是高频动作，2 倍在这里不是体验优化，是流水线吞吐。

--bytecode-order 这个参数名也透露了巧思：顺序可以指定，意味着构建者能按实际加载顺序喂给运行时——把"先用到的"排在前面，冷路径推后。这与"静态上下文只放多数轮需要的"是同一条原则换个场景：资源有限的地方，先到的都该是最常用的；无论那资源是上下文窗口还是启动时读的那截字节码。

给用 Bun 或关心启动的人一句落地的：先把你的入口脚本开上 bytecode 与 PGO 跑个基准——重点看两个数：冷启动耗时、以及热路径是否真的热（PGO 的收益完全取决于画像与真实负载是否吻合）；吻合，2 倍就在那里；不吻合，说明你的用法太偏门，通用画像罩不住，收益要打折算。