Ghostty 终端滚动缓冲压缩全解析Page 压缩表示、无分配 LZ4 Codec 与性能验证【免费下载链接】ghostty Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.项目地址: https://gitcode.com/GitHub_Trending/gh/ghostty终端模拟器在长时间运行后会积累大量滚动缓冲scrollback内存。Ghostty 采用「冷页面压缩 按需解压」的策略在后台把不再活跃的终端页terminal.Page压缩存储从而显著降低常驻内存占用。本文以 src/terminal/compress/AGENTS.md 为骨架结合Page.zig、lz4.zig、差分测试套件与基准工具源码完整讲解这套压缩子系统的设计优先级、压缩页表示、原始 LZ4 Block 编解码实现、测试与基准工作流。读完你既能掌握 Ghostty 滚动缓冲压缩的架构与取舍逻辑也能在其 page-shaped 语料 基准方法下复现验证流程。系统全景src/terminal/compress目录在终端内存体系中扮演的角色Ghostty 的终端渲染以「页」page为单位管理行缓冲每个终端页承载一块较大的连续 backing memory即terminal.Page.memory。当页面滚动出可视区、进入历史cold区域后系统希望释放其物理内存同时保留将来滚动浏览、搜索、inspector 读取时的还原能力。压缩子系统位于 src/terminal/compress/由聚合入口 compress.zig 对外暴露两类能力模块职责Page.zig压缩页表示保留原虚拟映射的完整TerminalPage元数据 精确尺寸的 LZ4 编码块lz4.zig无分配allocation-free的原始 LZ4 Block 编解码器lz4_differential.zig差分属性测试独立格式走查器、往返恒等、错误尺寸拒绝、损坏/截断解码安全性AGENTS.md本模块的工程指南优先级、测试、正确性、基准与性能结论compress.zig明确划定了职责边界表示与 codec 只负责编解码而「压缩哪些页、何时 decommit 常驻内存、何时还原」这类策略问题全部归PageList所有见 src/terminal/compress.zig。也就是说本文讲述的是这条流水线里的「表示 编解码」核心其调度逻辑在 PageList.zig 中实现。为什么压缩目标是页面背衬内存而不是普通文本AGENTS.md 的开篇即强调本目录压缩的是 terminal page backing memory压缩比评估必须基于 page-shaped 数据。终端页的背衬内存是包含 cells、rows、styles、graphemes、hyperlinks、allocator 元数据与未用容量的不透明字节快照其重复模式连续空格行、重复 cell、相似行结构与普通文本文件的统计特征差异很大。因此任何针对文本文件或合成数据的压测都只能作为次级信号。三项优先级压缩比 解压吞吐 压缩吞吐AGENTS.md 给出了处理一切权衡时的明确顺序这是理解本模块所有设计决策的钥匙页面形态数据上的压缩比Compression ratio on page-shaped data。编码后的字节会作为滚动缓冲内存长期保留而原始terminal.Page背衬内存是唯一真正被压缩的东西。能否省内存直接取决于此。解压吞吐Decompression throughput。页面只在变冷时压缩一次却会在滚动访问、搜索、inspector 检视时按需还原——还原是用户可感知的等待延迟因此解压速度权重高于压缩速度。压缩吞吐Compression throughput。压缩运行在空闲页面上的后台任务快是加分项、慢可以容忍。这一顺序贯穿了下述所有代码细节解码器为「每序列开销」做极致优化压缩端则允许使用相对较慢但更省内存的策略PageList将压缩安排到终端空闲时段增量执行详见下文「后台增量压缩调度」。压缩页表示Page.zig的完整状态保存与保留映射设计为什么要保存完整的 Page 值而非仅保存字节终端页有两类状态大块Page.memory分配背衬字节承载行、cell 内容相对较小的Page值内含偏移量、尺寸、脏标记、分配器元数据。并非所有后者都位于背衬内存中因此仅保留内存字节不足以还原页面。Page.zig的做法是完整保存Page值本身见 Page.zig 的模块注释。这与Page.cloneBuf的既有模型一致页内部使用偏移量引用数据所以只要内容在同一地址恢复浅拷贝的 Page 值依然有效。关键设计常驻映射刻意不释放Page.zig的头注释Page.zig解释了一个非直觉的设计压缩页类型刻意不释放常驻内存。真正的释放者是PageList——它保留虚拟地址区间同时请求操作系统丢弃其物理页。保留区间带来两个好处压缩态内的 Page 永远不会包含悬空指针还原页面不需要一次可能失败的分配recommit 一个保留的区间几乎不会失败。五步状态迁移意图中的状态迁移序列为源页面仍常驻时创建压缩值Page.init请求操作系统 decommit 源页面内存把 PageList 节点的常驻状态替换为压缩值需要还原时 recommit 保留区间并调用restore提交常驻状态后调用deinit释放编码字节。如果 decommit 不可用或失败调用方应销毁压缩候选让源页面保持常驻。Page类型本身不做任何虚拟内存操作——计划中的原生实现是 Linux 上使用MADV_DONTNEEDDarwin 上以MADV_FREE_REUSABLE搭配MADV_FREE_REUSE对于没有可靠「保留映射 decommit」操作的平台应直接关闭页压缩而不是释放后再重新分配常驻内存。成员与收益判断Page结构包含三个字段完整页元数据page、page.memory的精确 LZ4 原始块encoded以及拥有该块的分配器alloc。存储分配器让 PageList 节点能在无需回指 PageList的情况下自行还原或丢弃压缩状态。init的唯一目的是省内存其「盈利/不亏」判断值得注意Page.zigrequiredScratch(raw_len)返回能产生有用压缩表示的最大 scratch 尺寸。它刻意小于通用 LZ4 压缩上界压缩表示比常驻页多出一个 slice若编码块超过该上界就无法减少常驻内存。限制输出尺寸还允许 PageList 借用标准 page-pool 项作 scratch而无需保留更大的按压缩上界分配的缓冲Page.zig。压缩结果将「编码后尺寸 两种表示结构体的内存尺寸」与「常驻表示」做严格比较不能省内存就返回nullOutputTooSmall同样意味着越过盈亏平衡点。对应的单元测试 「compressed Page rejects a representation without savings」 用 FailingAllocator 验证把随机不可压缩数据塞满页内存后Page.init返回null且不诱导任何分配失败。restore 与 cloneBuf 两种还原路径restore()解码进被保留的常驻映射。调用方需先 recommitpage.memory平台要求时无论解码成败压缩值都保持有效允许调用方重试或丢弃。成功后返回的 Page别名同一块常驻映射不拥有新分配Page.zig。cloneBuf(memory)把页克隆到调用方拥有的内存中而不还原其映射供「只读消费者」使用——它们不应改动压缩表示。解码只写入提供的缓冲区因此被丢弃的page.memory内容与该压缩值均保持不变Page.zig。单元测试 「compressed Page retained mapping round trip」 完整演练了这条链路在页内存与 Page 值中同时置入状态cell 字符、组合附加字素、样式与超链接集合都保留了 Page.memory 之外的活跃计数器清零背衬字节模拟 decommit分别验证 clone、restore 后内存逐字节相等、脏标记与各集合引用含超链接 URIhttps://ghostty.org/docs的 slice 读取完好无损。另两个测试则锚定了 scratch 边界契约与错误编码下可重试的语义Page.zig、Page.zig。无分配 LZ4 Block 编解码器lz4.zig为什么只实现 block 而不实现 frameLZ4 有两层block 格式描述压缩字节frame 格式在其上加头、尺寸、校验和并支持多块流。终端页已有自己的所有权与元数据管理因此只实现 block。关键推论是编码块不携带解压后尺寸调用方必须自己保存尺寸解码时提供精确尺寸的输出缓冲lz4.zig。Block 序列编码结构一个 block 是一系列 sequence。每个非末尾 sequence 的形态为token | literal 长度扩展 | literals | offset | match 长度扩展token 的高半字节存 literal 长度、低半字节存match 长度 - 4半字节值 15 表示长度继续以扩展字节表示255 表示继续累加其后跟终止字节literal 字节直接拷贝随后两字节小端 offset 指回已解压输出中的匹配字节末尾 sequence 特殊只含 literals直接以 literals 收尾。参考格式还要求输入末尾 5 个字节必须是 literals、最后一次 match 必须在输入结束前至少 12 字节处开始。压缩器遵守这些限制使其产物可被按大块拷贝优化的外部 LZ4 解码器消费。本实现中的min_match 4、last_literals 5、match_find_limit 12正是这些常量lz4.zig。压缩端策略压缩采用 fast LZ4 策略对每 4 字节输入序列做哈希测试近期位置是否为候选匹配lz4.zig。值得注意的实现细节哈希表把两个 16 位位置打包进一个u32项格式不能回溯超过 64 KiB16 位足够表达位置。被挤掉的位置仍被保留为后备候选从而在哈希冲突后找回有用匹配而不增加固定 16 KiB 工作区。HashTable定义为[1 hash_log]u32即 4096 项 × 4 字节 16 KiB位移后的候选按 12 位哈希复用lz4.zig。全 1 半字表示空槽rememberPosition对低 16 位恰为0xFFFF的位置直接跳过。无匹配的长 run 会逐步跳过输入位置匹配 run 则以机器字为单位向后matchBegin和向前matchEnd扩展。向后扩展对「对齐 cell 记录」尤为有效——整字 XOR 后用clz/ctz定位首个差异字节由于按小端读取ctz恰好映射到内存中最早的差异字节。匹配结束后在接近结尾处播种一个位置使相邻的重复记录仍能引用回本次匹配lz4.zig。advanceSearch在字面量扫描的前 1 KiB 逐字节进行普通页面搜索开销低更长的无匹配 run 逐步加大步进以应对不可压缩数据。解码端为「百万次微小操作」设计的快路径decompress(input, output)的成功返回要求既消费完所有输入、又填满全部输出——这是对调用方维护的尺寸元数据的精确尺寸验证。解码器基于一个核心观察写成真实页数据的块中几乎所有 sequence 都是「短 literal 短 match」。因此两条快路径都盲拷贝固定字节数再由长度算术决定其中多少有效运行长度在阈值以下≤14 字节且两侧缓冲余量 ≥16 时用一次 16 字节宽拷贝覆盖整个 literal runmatch 长度在 4–18 字节且 offset ≥8、输出余量 ≥18 时用 3 次盲拷贝u64u64u16覆盖整段 match重叠时也能正确传播重复周期offset ≥ 字宽时每次 load 都落在可能观察到它的 store 之前整整一个字。越界安全性有赖于一个精妙的论证lz4.zig在拷贝逻辑终点之后多写的 scratch 字节是安全的前提是写入不越过输出缓冲——因为顺序解码会在任何 match 读到它们之前重写这些字节。这就是 AGENTS.md 中「不削弱精确尺寸输出契约」的底层来源。容错路径与精确检查的边界如下表错误触发条件TruncatedInput编码块在 sequence 中途结束InvalidOffsetmatch offset 为 0 或指向已产出字节之前OutputTooSmallsequence 将写出提供的输出缓冲OutputSizeMismatch块结束但未填满精确尺寸输出缓冲解压端对最长可引用 offset 也做了兼容验证匹配长度可扩展至u16最大 offset 场景的测试见 lz4.zig。compressBound对外提供单次分配、任意 ≤max_input_size输入可复用的输出上界lz4.zig。后台增量压缩调度与PageList的衔接策略层在 PageList.zig 中节点数据是resident或compressed联合体压缩节点保存compression.PagePageList.zig。还原发生在「透明内容访问边界」Node.page上——只有compressed节点才触发 recommit restore并且可以选择.preserve解码后丢弃编码块或.discard不解码直接丢弃用于真正销毁。增量压缩由PageList.page_compressionIncrementalCompressionState驱动每次活动markActivity都会使该状态重新调度压缩只在空闲后台推进只有一整轮零压缩的「验证遍历」通过后压缩才算真正转入空闲从而保证被搜索、滚动或 inspector 解压过的页面会被重新压缩PageList.zig。单步候选检查有上限incremental_compression_max_inspected 8见 PageList.zig以时间片约束后台压缩。对外入口compress(.full | .incremental | .drain)分别对应整趟压缩、单步增量与排干式反复增量。候选页的收益评估复用Page.requiredScratch失败即视为「不可压缩」压缩成功后先 tripwire 检查 decommitPageList.zig再把节点置为.compressed。也就是说真正省下的内存来自 decommit 丢弃的物理页编码块只是「换一种更小的常驻形态」。测试与正确性验证从定向过滤到差分属性套件三条跑测命令AGENTS.md 规定的测试入口codec为lz4等过滤词定向测试zig build test -Dtest-filtercodec优先用zig build test-lib-vt -Dtest-filtercodec——本代码随 libghostty-vt 发布这条路径更贴近交付物codec 必须能面向wasm32-freestandinglibghostty-vt构建不能依赖 libc、不能依赖 src/simdHighway验证命令zig build -Demit-lib-vt -Dtargetwasm32-freestanding -DoptimizeReleaseSmall。每个 codec 都必须具备的差分属性套件要求覆盖四类性质往返恒等round-trip identity解压必须逐位还原输入独立格式走查器与 codec 无共享代码的独立实现校验编码块结构合法、且满足本文档化的更严格保证末尾 5 字节为 literal、match 不晚于末尾 12 字节开始——防止 codec 回归悄悄削弱检查错误尺寸拒绝向小于与大于精确长度的缓冲解压都必须报错分别对应OutputTooSmall与OutputSizeMismatch损坏/截断解码安全对合法块做位翻转、字节覆写、随机拼接、截断前缀等变异后喂给解码器——任何结果都可接受干净失败或成功唯独不允许越界读写。轻量版跑在常规单元测试中穷举版必须用环境变量门控保持默认测试套件快速。lz4_differential.zig的生成器矩阵与预算差分套件lz4_differential.zig用 7 类确定性生成器覆盖不同 codec 行为生成器模拟形态random_bytes均匀随机接近不可压缩测最坏情形runs随机长度单字节 run周期 1 匹配periodic单一重复周期贯穿全块cells8 字节记录 随机小负载 零填充模拟终端 cell 内存words字典词 分隔符文本式 literal/match 混合sparse大量零 零星随机字节长 match 间孤立 literalmixed上述生成器的随机分段测状态迁移轻量预算light_budget覆盖边界尺寸token 半字节 14/15、最小 match 与 find 限制 4/12、长度扩展步进 15255k、2 的幂邻域、24 个随机输入与显式匹配周期1/2/3/4/8/9/17/65534/65535/65536/65537——覆盖每种拷贝策略与 64 KiB 窗口边缘共 64 次损坏解码。穷举预算exhaustive_budget将扫描上界提升到 2048、随机输入 512 个、输入最大 512 KiB、周期枚举 41 个、每次 4096 次变异并额外做全前缀截断扫描对合法块的每个前缀都尝试解码。穷举测试以 4 个独立种子运行默认跳过仅当环境变量开启时执行GHOSTTY_LZ4_SLOW1 zig build test -Dtest-filterlz4 differential用「安全构建的运行时越界即失败」做内存安全兜底AGENTS.md 强调解码器必须对任意输入字节内存安全。测试构建开启了运行时安全检查任何越界 slice 访问都会令测试失败——这正是上述变异测试能够验证内存安全的机制。此外所有盲拷或宽拷贝都需要显式的 margin 参数把拷贝限定在输出缓冲内并把 margin 的论证以注释形式留在代码旁解码器的注释正是这样做的。基准工作流ghostty-bench page-compression构建与模式构建命令参考 src/benchmark/AGENTS.md 的通用流程zig build -Demit-bench -DoptimizeReleaseFast -Demit-macos-appfalsepage-compression模式只测独立 LZ4 block codec输入视为不透明字节PageCompression.zig。四种模式如下另有noop基线模式测什么计时区内行为compress压缩吞吐每页压缩进可复用输出缓冲无分配decompress解压吞吐setup 阶段预压缩好所有块计时区只解码到可复用缓冲store精确编码存储成本压缩 精确尺寸分配 有界环形保留模拟滚动缓冲的分配、淘汰与 allocator 复用分配刻意留在计时区内report压缩比每页压缩一次并打印 raw/encoded/ratio不是计时基准数据集加载、输出分配与解压预准备都发生在setup计时区之外。store的--retained-pages默认 25近似由 400 KiB 标准页组成的 10 MB 滚动缓冲PageCompression.zig。语料选择最具代表性的是真实页背衬内存 dump默认--page-size为 400 KiBReleaseFast 目标上标准终端页的尺寸文件按块切分尾块不足一块时也保留最代表性语料是真实页背衬内存的原始 dump含 cells、rows、styles、graphemes、hyperlinks、allocator 元数据与未用容量——codec 实际看到什么就测什么可补充文本语料与随机字节测最坏情形但按优先级应最看重 page 语料语料放在仓库之外跨比较复用完全相同的文件配合hyperfine做多 warmup、取中位数。ratio 检视示例命令形态与源码注释一致ghostty-bench page-compression --modereport --data/tmp/pages.raw对比精确存储成本与纯 codec 成本hyperfine --warmup 3 \ ghostty-bench page-compression --modecompress --loops100 --data/tmp/pages.raw \ ghostty-bench page-compression --modestore --loops100 --data/tmp/pages.raw区分两种基准page-compression与scrollback-compressionghostty-bench scrollback-compressionScrollbackCompression.zig则先解析 VT 语料构造真实 Terminal其计时操作包含 PageList 状态迁移、精确编码分配、保留映射回收与经Node.page的透明还原——测的是 codec周围的过渡开销而非 codec 本身。它固定操作主屏 PageList--max-scrollback默认 10 MBincremental模式计时区包含候选受限的增量步进与最后的零工作验证遍历从而与一次性compress直接可比。对应测试还验证了「restore 后页可被再次压缩」与「incremental 与 monolithic 最终存储表示一致」ScrollbackCompression.zig。快速迭代独立 harness 直接构建 codec为快速迭代codec 只依赖std因此可用独立 harness 直接构建zig build-exe -O ReleaseFast进程内计时 codec报 min-of-N 并验证往返。原则上是一次只改一处、最后重测最终状态run-to-run 噪声为百分之几量级小差异必须重跑确认。实测性能结论为什么「分支稀疏 盲定长拷贝」能赢AGENTS.md 沉淀了三条来自真实 page 数据测量而非文本语料直觉的经验真实页数据解压是数百万次微小操作LZ4 中多为「零个 literal 一段 4–18 字节 match」。每项开销per-item overhead主导一切所以少分支的快路径 盲定长拷贝最占优——分支越少、每次 sequence 的固定开销越小。宽拷贝是这里唯一值得用的 SIMD。向量化比较与其他宽步进技巧实测为净亏损因为 match 很短向量化没有足够的并行长度可榨取在 page 语料上有实测依据前坚持朴素字循环。memcpy只在长拷贝约 64 字节起时胜过步进循环更短时函数调用开销反而吃亏——所以copyMatch里只有在offset match_len且match_len 64的非重叠远距匹配才走单次memcpy其余场景用模式字展开offset 1/2/4/8 变为独立 store无等待前序 store 的 load与u64/u128宽循环offset ≥8/≥16 时。这些结论解释了解码器为何几乎全部由「先宽拷贝、后算长度」的快路径构成——它在微观层面把每次 sequence 的分支与簿记压到最低与「解压吞吐优先于压缩吞吐」的优先级一脉相承。实用速查把工程指南变成日常命令面向本模块贡献与验证的可复现命令清单全部以仓库根目录为前提、在已配置 Zig 的环境运行# 定向跑 LZ4 codec 单元测试 zig build test -Dtest-filterlz4 # 以 libghostty-vt 的形态跑本代码随 libghostty-vt 交付 zig build test-lib-vt -Dtest-filterlz4 # 穷举差分属性套件慢须显式开启 GHOSTTY_LZ4_SLOW1 zig build test -Dtest-filterlz4 differential # 验证 codec 的 wasm32-freestanding 可构建性无 libc、无 src/simd/Highway zig build -Demit-lib-vt -Dtargetwasm32-freestanding -DoptimizeReleaseSmall # 构建基准工具 zig build -Demit-bench -DoptimizeReleaseFast -Demit-macos-appfalse # 检视 page 语料的压缩比非计时 ghostty-bench page-compression --modereport --data/tmp/pages.raw另外当一次改动不应改变压缩输出时AGENTS.md 要求用同一语料比较改动前后的**编码总尺寸或 sequence 计数指纹**来证明——压缩率漂移属于功能性变更不能当作噪声放过。这也是本模块「数据驱动取舍」工程文化的最终落脚点从优先级、差分测试到基准语料所有设计都在回答同一个问题——在真实终端页形态的数据上如何以最小且可验证的代价换回最多的滚动缓冲常驻内存。【免费下载链接】ghostty Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.项目地址: https://gitcode.com/GitHub_Trending/gh/ghostty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
