10MB装下一个Node应用揭秘Lexe字节码编译器的lrt格式与zstd字典压缩【免费下载链接】lexePackage your Node.js application into a single executable file, but only 10MB.项目地址: https://gitcode.com/gh_mirrors/le/lexeLexe 是一个轻量级 JavaScript 运行时能把 Node.js 应用打包成仅 8~10MB 的单个可执行文件。它的小巧身材并非简单砍功能而是靠一套巧妙的工程方案字节码编译器生成.lrt文件再用zstd 字典压缩把体积进一步压到极限同时让冷启动快好几倍。本文带你从字节层面拆解这套方案。上图为 Hello World 打包体积对比Lexe 仅 8.31MB而 deno 64.31MB、bun 54.38MB、pkg 44.14MB为什么用字节码从“带源码”到“带机器码”传统打包方案如 pkg会把 JS 源码原样塞进二进制运行时再现场解析、编译。Lexe 走的是另一条路构建期QuickJS 引擎把 JS 源码一次性编译成字节码类似 Java 的 .class 思路构建期字节码用 zstd 字典压缩后以.lrt扩展名落盘并直接嵌入最终二进制运行期跳过解析和编译直接Module::load加载字节码好处有三体积更小字节码比源码紧凑、启动更快省去编译开销、源码不落地天然混淆。lrt 文件格式全解6字节文件头长什么样打开任意一个.lrt文件它的结构可以用一张表说清。定义见 llrt_core/src/bytecode.rs偏移长度内容说明05 字节lrt01版本签名BYTECODE_VERSION51 字节c或uc已压缩u未压缩64 字节原始大小仅压缩时存在小端 u3210剩余负载zstd 压缩流 / 裸字节码也就是说压缩文件lrt01c 4字节原始长度 zstd 数据未压缩文件lrt01u 裸字节码写入头部的是 add_bytecode_header 函数读取时运行时会先校验签名和版本不合法会直接报Invalid bytecode version。zstd 字典压缩为什么比裸 zstd 更狠字典是什么zstd 支持压缩字典一份从样本数据中训练出来的公共模板本项目上限 40KB压缩时把它当作已知上下文重复出现的模式就不用再描述一遍。字节码里充斥大量重复的指令序列和常量对象操作、字符串引用对字典压缩来说是天菜。Lexe 的三步字典压缩流程第 1 步训练字典离线一次性zstd --train --train-fastcoversteps60 --maxdict40K -o compression.dict *.lrt训练逻辑见 generate_compression_dictionary。第 2 步构建期压缩compress_bytecode 对每个字节码文件执行zstd --ultra -22 -f -D prebuild/compression.dict也就是最高压缩档位22 级 预置字典最后补上.lrt文件头。第 3 步运行期解压字典 prebuild/compression.dict 在 llrt_core/src/vm.rs 中通过include_bytes!直接嵌入可执行文件加载模块时用它重建解压字典见 loader.rs 的 get_module_bytecode解压后交给 QuickJS 直接执行。 字典是预生成而非构建时现练的因为跨平台训练的字典可能不通用——这一说明写在 prebuild/README.md。压缩链路一览JS 源码 → Module::declareQuickJS编译→ 字节码 → zstd level-22 字典压缩 → 加 lrt01 头 → .lrt → 嵌入二进制核心代码在 compress_moduleCompressor::with_dictionary(22, COMPRESSION_DICT)一行就点出了22 级 字典的组合拳。此外 Makefile 还会为 arm64/x64 交叉编译静态链接libzstd.a保证目标平台零依赖。性能收益冷启动快到什么程度字节码 压缩不是只省体积Lambda 冷启动收益非常直观。下图是 Lexe 运行 DynamoDB PutItem 场景的延迟分布冷启动 p50 仅 64.16ms热启动 p50 低至 14.94ms作为对照Node.js 20 同样场景冷启动 p50 高达 1511.93ms约为 Lexe 的 24 倍差距主要就来自现场编译源码 vs 直接加载预编译字节码。源码导航五分钟看懂这条管线环节位置文件头定义与拼装llrt_core/src/bytecode.rsJS → 字节码 → 压缩llrt_core/src/compiler.rs字典训练与批量压缩llrt_core/build.rs预置字典文件prebuild/compression.dict运行时解压加载llrt_core/src/modules/require/loader.rs命令行入口lexe compilellrt/src/main.rs总结Lexe 的10MB 魔法可以浓缩成三句话字节码先行QuickJS 预编译字节码替代运行时编译更小更快lrt 极简格式5 字节签名 1 字节标志 可选 4 字节长度清晰可校验zstd 字典压缩40KB 预训练字典 22 级压缩把重复模式删掉运行时零成本还原对于 CLI 工具和高并发冷启动场景这套字节码 字典组合拳值得每个做打包工具的人研究。【免费下载链接】lexePackage your Node.js application into a single executable file, but only 10MB.项目地址: https://gitcode.com/gh_mirrors/le/lexe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 10MB装下一个Node应用？揭秘Lexe字节码编译器的lrt格式与zstd字典压缩
10MB装下一个Node应用揭秘Lexe字节码编译器的lrt格式与zstd字典压缩【免费下载链接】lexePackage your Node.js application into a single executable file, but only 10MB.项目地址: https://gitcode.com/gh_mirrors/le/lexeLexe 是一个轻量级 JavaScript 运行时能把 Node.js 应用打包成仅 8~10MB 的单个可执行文件。它的小巧身材并非简单砍功能而是靠一套巧妙的工程方案字节码编译器生成.lrt文件再用zstd 字典压缩把体积进一步压到极限同时让冷启动快好几倍。本文带你从字节层面拆解这套方案。上图为 Hello World 打包体积对比Lexe 仅 8.31MB而 deno 64.31MB、bun 54.38MB、pkg 44.14MB为什么用字节码从“带源码”到“带机器码”传统打包方案如 pkg会把 JS 源码原样塞进二进制运行时再现场解析、编译。Lexe 走的是另一条路构建期QuickJS 引擎把 JS 源码一次性编译成字节码类似 Java 的 .class 思路构建期字节码用 zstd 字典压缩后以.lrt扩展名落盘并直接嵌入最终二进制运行期跳过解析和编译直接Module::load加载字节码好处有三体积更小字节码比源码紧凑、启动更快省去编译开销、源码不落地天然混淆。lrt 文件格式全解6字节文件头长什么样打开任意一个.lrt文件它的结构可以用一张表说清。定义见 llrt_core/src/bytecode.rs偏移长度内容说明05 字节lrt01版本签名BYTECODE_VERSION51 字节c或uc已压缩u未压缩64 字节原始大小仅压缩时存在小端 u3210剩余负载zstd 压缩流 / 裸字节码也就是说压缩文件lrt01c 4字节原始长度 zstd 数据未压缩文件lrt01u 裸字节码写入头部的是 add_bytecode_header 函数读取时运行时会先校验签名和版本不合法会直接报Invalid bytecode version。zstd 字典压缩为什么比裸 zstd 更狠字典是什么zstd 支持压缩字典一份从样本数据中训练出来的公共模板本项目上限 40KB压缩时把它当作已知上下文重复出现的模式就不用再描述一遍。字节码里充斥大量重复的指令序列和常量对象操作、字符串引用对字典压缩来说是天菜。Lexe 的三步字典压缩流程第 1 步训练字典离线一次性zstd --train --train-fastcoversteps60 --maxdict40K -o compression.dict *.lrt训练逻辑见 generate_compression_dictionary。第 2 步构建期压缩compress_bytecode 对每个字节码文件执行zstd --ultra -22 -f -D prebuild/compression.dict也就是最高压缩档位22 级 预置字典最后补上.lrt文件头。第 3 步运行期解压字典 prebuild/compression.dict 在 llrt_core/src/vm.rs 中通过include_bytes!直接嵌入可执行文件加载模块时用它重建解压字典见 loader.rs 的 get_module_bytecode解压后交给 QuickJS 直接执行。 字典是预生成而非构建时现练的因为跨平台训练的字典可能不通用——这一说明写在 prebuild/README.md。压缩链路一览JS 源码 → Module::declareQuickJS编译→ 字节码 → zstd level-22 字典压缩 → 加 lrt01 头 → .lrt → 嵌入二进制核心代码在 compress_moduleCompressor::with_dictionary(22, COMPRESSION_DICT)一行就点出了22 级 字典的组合拳。此外 Makefile 还会为 arm64/x64 交叉编译静态链接libzstd.a保证目标平台零依赖。性能收益冷启动快到什么程度字节码 压缩不是只省体积Lambda 冷启动收益非常直观。下图是 Lexe 运行 DynamoDB PutItem 场景的延迟分布冷启动 p50 仅 64.16ms热启动 p50 低至 14.94ms作为对照Node.js 20 同样场景冷启动 p50 高达 1511.93ms约为 Lexe 的 24 倍差距主要就来自现场编译源码 vs 直接加载预编译字节码。源码导航五分钟看懂这条管线环节位置文件头定义与拼装llrt_core/src/bytecode.rsJS → 字节码 → 压缩llrt_core/src/compiler.rs字典训练与批量压缩llrt_core/build.rs预置字典文件prebuild/compression.dict运行时解压加载llrt_core/src/modules/require/loader.rs命令行入口lexe compilellrt/src/main.rs总结Lexe 的10MB 魔法可以浓缩成三句话字节码先行QuickJS 预编译字节码替代运行时编译更小更快lrt 极简格式5 字节签名 1 字节标志 可选 4 字节长度清晰可校验zstd 字典压缩40KB 预训练字典 22 级压缩把重复模式删掉运行时零成本还原对于 CLI 工具和高并发冷启动场景这套字节码 字典组合拳值得每个做打包工具的人研究。【免费下载链接】lexePackage your Node.js application into a single executable file, but only 10MB.项目地址: https://gitcode.com/gh_mirrors/le/lexe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考