rustgzip 0.5.2__tar.gz

rustgzip-0.5.2/.cargo/config.toml

@@ -0,0 +1,5 @@
+[source.crates-io]
+replace-with = "vendored-sources"
+
+[source.vendored-sources]
+directory = "vendor"

rustgzip-0.5.2/ARCHITECTURE-BOTTLENECK-AUDIT.md

@@ -0,0 +1,301 @@
+# 普通 gzip 并行解压架构审计
+
+审计日期：2026-10-21。目标是解释为什么局部优化多次有效，普通日志仍无法超过
+顺序基线，而不是继续添加微优化开关。本轮没有修改生产解码算法、依赖或 Python
+API，只增加开发测量工具和一个 test-only 的已知检查点诊断模式。
+
+## 结论
+
+目前的系统有两个相互牵制的瓶颈：
+
+1. 完整推测解码可以提前做较多工作，但符号解码器的每字节成本高，协调器还
+   顺序回填整片符号和计算 CRC，四个 worker 补不回这些额外成本。
+2. 通过 256 KiB 未知前缀提前交付和协调器原生接续，避开了大量慢符号工作，
+   却把日志约 89.7% 明文的原生解码放回一条串行链。其单 worker 与四 worker
+   吞吐几乎相同。后来的缓冲、快照和通知优化主要在缩减这条串行链的附加成本。
+
+因此，“退回完整推测”与“更早切原生”单独做都不够。要大幅改变扩展性，需要
+让未知历史片段在真实前驱尚未完成时也能**高效地完成第一阶段**，并把串行职责
+缩到末尾窗口传播，而不是让协调器继续承担整片解码和整片回填。
+
+这是当前输入和代码证据支持的架构判断；不是所有 gzip 文件的普遍下界。
+
+## 1. 本轮如何交叉验证
+
+第一轮：核对本地任务、预算、交付和提交代码，回看已有时间线。
+第二轮：查阅原始 rapidgzip 论文，重点核对两阶段、窗口传播和停止规则。
+第三轮：查阅 rapidgzip 当前关联源码与独立 Rust 实现的公开审计，区别算法结构
+和单机 SIMD/汇编优化；随后做本地三路径反事实测试。
+第四轮：新增提前准备真实检查点的独立原生任务对照，区分后端潜力与首次解压
+的字典发现成本。其准备成本明确不计入计时，不能当产品速度。
+
+本机处理器读取得到 Intel Core Ultra 9 275HX、24 核/24 逻辑处理器。它包含
+性能核和能效核：[Intel 官方规格](https://www.intel.com/content/www/us/en/products/sku/242293/intel-core-ultra-9-processor-275hx-36m-cache-up-to-5-40-ghz/specifications.html)。
+已有测量只固定协调/计时线程 CPU 0，worker 仍由系统调度，没有逐 worker 核型、
+频率、温度或 PMU 采样。因此百分之几的波动不能直接解释成某个缓存或分支因素。
+线程占用区间也不等于 CPU 使用时间。
+这里的“4 worker”另有一个协调线程，不是全进程总共四个线程；同理“1 worker”
+也不能自动解释为仅用一个核心。所有核心吞吐来自 Rust 测量入口，Python 工具
+只启动进程和收集结果；本次扩展问题在未经过 Python 解码接口时已出现，不能
+归因于 Python 3.4 或 GIL。
+
+## 2. 目前真正运行的任务图
+
+```mermaid
+flowchart TD
+    A[压缩位网格与候选搜索] --> B[未知历史 worker]
+    B --> C{窗口中的 Marker 是否消失}
+    C -->|消失| D[原生后缀独立解码]
+    C -->|持续存在| E[约 256 KiB 后在完整块边界提前交付]
+    E --> F[协调器等待可信前驱并验证窗口]
+    F --> G[协调器原生顺序接续大片数据]
+    D --> H[协调器按顺序提交]
+    G --> H
+    H --> I[符号回填 / CRC / 输出事务]
+    I --> J[下一片真实历史]
+```
+
+候选从压缩区间内的合法块头开始，原生后端仍严格要求真实窗口。`history-feedback`
+只能把精确起点的字典发给尚未结束的任务；本次日志四 worker 样本 applied=0，
+不能把“反馈机制存在”当作它已经打通并发交接的证据。
+
+需要核对的本地位置：
+
+- `src/decompress_parallel/file_pool.rs` 的 `decode_task_with_history`：原生选择、
+  256 KiB 提前交付、压缩网格终点与输出预算。
+- 同文件 `Pool::lookup`：只在精确起点匹配时采用候选；可信任务拿到历史后才建立。
+  `direct_known` 启动后，后继通常返回协调器直接执行。
+- `src/decompress_parallel/file_verify.rs`：`validated_tail` 只解析候选末尾窗口，
+  但之后的批次循环仍调用 `FileChunk::read` 回填整片符号，并顺序计算 CRC。
+- `FileLease::Drop`：结果被完整消费后才释放其槽位和内存信用，没有独立的
+  “窗口已传播但全文后处理尚未完成”的任务状态。
+
+精确起点、历史验证、失败回滚与内存信用都是需要保留的正确性约束。性能重构
+应改变工作分配和对象生命周期，不能删掉这些约束。
+
+## 3. 本轮反事实测试：三个策略为何都不理想
+
+[原始五轮数据](architecture-audit-128m.json)，128 MiB 热缓存，交错执行，取中位数。
+计时包含线程启动/回收，不含进程启动/编译；同源码构建三个 release 程序。
+2 MiB 压缩网格、4 MiB 单任务输出额度、64 KiB 批次、最多 128 块/任务。
+
+- full_symbolic：实际 feature 为 `history-feedback`，取消提前交付，继续推测。
+  这个标签不是说全文件都用符号；已知历史或已消除 Marker 的部分仍用原生。
+- yield_then_worker：`unknown-prefix-yield`，交付前缀后用携带真实历史的 worker 接续。
+- current：`lazy-native-history quiet-idle-workers`，主要由协调器原生接续。
+
+单位 MiB/s：
+
+| 输入与策略 | 1 worker | 2 worker | 4 worker | 1→4 扩展 |
+|---|---:|---:|---:|---:|
+| 日志，完整推测 | 209.49 | 342.37 | 380.52 | 1.82 倍 |
+| 日志，前缀交付后派发可信任务 | 434.58 | 533.99 | 484.03 | 1.11 倍 |
+| 日志，当前协调器接续 | 693.82 | 590.13 | 701.02 | 1.01 倍 |
+| 随机 Base64，完整推测 | 303.15 | 572.03 | 840.03 | 2.77 倍 |
+| 随机 Base64，前缀交付后派发可信任务 | 319.46 | 552.07 | 801.99 | 2.51 倍 |
+| 随机 Base64，当前协调器接续 | 324.69 | 576.40 | 865.97 | 2.67 倍 |
+
+同轮顺序基线：日志 819.86、随机 474.76 MiB/s。
+不建池、仍走块级验证层的 native-only：日志 728.75、随机 329.55 MiB/s。
+后者不是理想后端裸吞吐：它仍有逐块处理、窗口、状态检查、CRC 和提交开销，
+诊断用 Direct 来源也会请求历史。它与顺序 Decoder 的差距不能全归咎于某一项。
+
+### 3.1 当前路径的并行主体很小
+
+当前日志四 worker 的一条普通计时样本，明文总量 134217728 字节：
+
+| 工作类别 | 字节数 | 占总明文 |
+|---|---:|---:|
+| 协调器原生解码 | 120330356 | 89.65% |
+| 被采用的 worker 原生输出 | 8994615 | 6.70% |
+| 被采用的 worker 符号输出 | 4892757 | 3.65% |
+
+worker 合计只完成约 10.35% 有效明文。原生处理总占比约 96.35%，但绝大部分
+在协调器，不是四核原生并发。用“原生覆盖率高”证明多核扩展，指标选错了。
+
+原先 yield_then_worker 的 worker 原生量达 120743133 字节，却依赖前序窗口逐个
+接续。把串行任务从协调器搬到 worker，并不会让它们自动独立。
+
+### 3.2 时间线与字节归属相互印证
+
+[单独计时诊断与时间线摘要](architecture-audit-timeline-summary.json)；诊断开时钟
+和 trace，不能替代上表普通测量，也不能把不同线程累计墙钟直接相加。
+
+日志 current 诊断：总墙钟约 178.72 ms，协调器批次解码约 144.20 ms，
+等待约 17.48 ms，CRC 约 3.49 ms。worker 平均任务占用约 0.58 个，不是 CPU
+核利用率；最后一个 worker 在约 99.54 ms 完成，后面还有约 79 ms 主要由
+协调器继续推进。不是四个 worker 一直在有效解码。
+
+日志 full_symbolic：总墙钟约 314.56 ms，worker 符号阶段累计约 480.88 ms，
+协调器批次解码/符号回填约 82.71 ms，CRC 约 7.14 ms。
+这说明完整推测确实把工作分给更多 worker，但符号处理和串行全文回填成本高。
+
+随机 current：worker 平均任务占用约 3.42 个、四 worker 约 866 MiB/s，
+与“同一个池可以并行，只是日志任务失去了独立性”的判断一致。
+
+### 3.3 候选失败和重复解码不是本样本的主因
+
+日志四 worker 三组的候选重试均为 0，拒绝历史为 0；约 115 万个搜索 bit
+位置，说明搜索有成本，但没有大量假候选失败。完整推测组未采用/重复量约
+0.98 MB，current 约 0.073 MB，相比 128 MiB 总量很小。
+扫描累计约 45–51 ms，分布在 worker 上且与解码重叠，不能当作总墙钟占比。
+本轮证据不支持优先继续优化假候选剪枝或声称“重复解码吞掉大半时间”。
+
+日志组块内重放 attempts=0；持续 Marker 阻止窗口变成真实字节。进一步改进
+仅在窗口已知时才能启动的块内重放，无法直接覆盖这条日志主路径。
+
+### 3.4 提前提供真实字典后的原生扩展对照
+
+`tools/audit_preindexed_native.py` 增加了一个 test-only 诊断：先完整验证单 member
+并收集约 2 MiB 压缩间隔处的真实块起点和字典，然后**在准备完成后重新计时**，
+独立任务使用原生后端解码、计算局部 CRC，末尾按顺序合并 CRC、长度和块数，
+与前一遍已验证结果核对。创建/回收线程、计时内输入读取和 CRC 均包含。
+
+它排除了候选搜索、第一次构造字典和符号中间结果，也不保留全量明文；单任务
+可以连续读完整个已知区间，不受旧的 4 MiB 结果缓存限制。因此这是定位工具，
+不是当前调度器只需一个开关就能达到的成绩，更不是无索引首次解压成绩。
+
+字典准备虽不计时，但实际执行且有开销；不能省略它再向用户报“普通 gzip
+已经达到数 GB/s”。两组都是热缓存。普通测量记录中的线程 cycles 探针包围了
+准备过程，不能用该值解释 oracle 的纯计时段 CPU 成本。
+
+最终数据见 [已知检查点诊断](architecture-preindexed-diagnostic.json)。
+固定源码五轮中位数，单位 MiB/s：
+
+| 输入 | 同轮顺序基线 | 已知索引 1 worker | 2 worker | 4 worker |
+|---|---:|---:|---:|---:|
+| 日志 | 907.40 | 919.89 | 1579.86 | 2772.19 |
+| 随机 Base64 | 467.03 | 478.79 | 882.44 | 1522.11 |
+
+日志有 16 个真实字典任务，随机有 49 个；原生任务 1→4 分别约扩展 3.01 倍、
+3.18 倍，验证 CRC、长度和块数一致。它证明后端和当前机器能执行有效的独立
+原生并行任务，但没有证明无索引时能够低成本获得这些字典，也没有证明保留
+全量 bytes 输出时仍有相同数字。不同表的顺序基线各自同轮，不能跨表相减
+推导某一个具体步骤耗时。
+
+本轮三路径测量完成后，仅追加了这个诊断 helper 及默认构建的 feature guard；
+生产解码文件不变。两个阶段分别记录其当时源码摘要，不能声称所有 JSON 的
+测试文件摘要完全一致。
+
+## 4. 为什么完整符号路径成本高
+
+这些是源码中确认存在的操作，还没有 PMU/函数级采样证实各自 CPU 占比，
+不能随意排出精确百分比：
+
+1. `FileBits::transaction` 在每个 literal/match token 周围建立有界 BitCursor，
+   检查输入、取消、逻辑范围、重试条件和提交位置。它是可靠的恢复型解析器，
+   但尚不是“缓存输入上的连续快速 inflate 循环 + 少量尾部慢路径”。
+2. `BitCursor::peek_bits` 对所需位逐字节拼接，没有持续的宽位缓存。Huffman
+   主表默认 8 位，长码逐位回退。扩大主表单独做过，但不能替代整个 token 循环设计。
+3. LZ77 匹配先写输出 Vec，又维护一份 32 KiB u16 环形历史；`SymbolWindow::extend`
+   统计被覆盖的旧 Marker 和进入的新 Marker，再复制。批量复制已实现，但每批
+   仍有两份符号存储的流量和依赖统计，不是单纯将 u8 换成 u16。
+4. 每批新建符号 Vec；本地 batch、任务总 symbols、窗口之间仍有搬运。回填时
+   又分配真实字节批次，全文由协调器遍历。CRC 另读一次真实输出。
+
+不能笼统地说“纯 Rust 必然慢”或“u16 必然无法批量/SIMD”。应先隔离基于输出
+历史的连续符号内核，测每 token 指令成本、match 长度和 Marker 分布，再决定
+宽加载、表布局或 SIMD。安全尾部、重叠复制和 Marker 传播语义必须保留。
+
+## 5. 必须纠正的 32 KiB 前提
+
+最大直接回溯距离是 32 KiB，不意味着解出 32 KiB 后未知引用消失。一个尚未
+确定的字节，可以被 distance=1 的重复匹配一直传播；解出几 MiB 后尾窗口仍
+全是它的 Marker。代码使用 unknown_count==0 的判断是必要的。
+
+因此，阶段 6 的原生交接在随机数据很有价值，但不能作为日志的普遍解决方案。
+“前 0.2% 慢解析，后 99.8% 一定原生”这个估算没有普适性。更宽松的交接条件
+若不能证明所需真实字典已知，会把性能问题变成正确性问题。
+
+[RFC 1951](https://www.rfc-editor.org/info/rfc1951/) 规定跨块回溯及距离上限；
+它没有保证历史内容的依赖经过一个窗口后必然消失。
+
+## 6. 与公开实现的根本差异
+
+[rapidgzip 原始论文 §2.2、§3.3](https://arxiv.org/html/2308.08955v1) 的关键结构是：
+先做未知历史解码，再传播片尾窗口，全文 Marker 替换可并行；窗口全真实时才
+退回普通解码。串行依赖是窗口传播，不应扩大为大片实际解码。
+
+进一步核对当前 rapidgzip 所引用的 librapidarchive 固定提交
+`1221a30bb548b305a69e5715f2bc348ba37ac243`：
+[GzipChunkFetcher](https://github.com/mxmlnkn/indexed_bzip2/blob/1221a30bb548b305a69e5715f2bc348ba37ac243/src/rapidgzip/GzipChunkFetcher.hpp)
+的 `queueChunkForPostProcessing` 先建立下一个窗口，再提交 `applyWindow` 任务；
+[ChunkData](https://github.com/mxmlnkn/indexed_bzip2/blob/1221a30bb548b305a69e5715f2bc348ba37ac243/src/rapidgzip/ChunkData.hpp)
+在真实数据就绪后处理局部 CRC。我们的文件提交路径目前仍逐批回填并顺序 CRC，
+没有这个独立的并行后处理阶段。
+
+另一个公开 Rust 实现的
+[性能审计](https://github.com/COMBINE-lab/rapidgzip-rust/blob/main/PERFORMANCE_AUDIT.md)
+也将输出作为符号历史、仅串行解析尾窗口、并行全文回填列为架构改动。
+这是交叉验证方向，不能把其硬件成绩移植成我们的性能承诺，也不表示必须依赖
+该项目；本轮没有复制它的实现代码。
+
+## 7. 任务粒度和资源模型也需要重构
+
+本轮日志压缩后约 30.04 MiB，膨胀比约 4.26；一个 2 MiB 压缩网格平均覆盖
+约 8.52 MiB 明文，但任务总输出额度仅 4 MiB，再加最多 128 块的限制。
+于是一个物理区间经常无法由一次任务覆盖；更激进的 256 KiB 提前交付使 worker
+只留下约 0.3 MiB 符号，后继大片又回到可信链。这些额度分别保证了安全，却
+没有共同围绕“可采用的独立片段”设计。
+
+直接把额度翻倍并不等于解决：额度提高会使每槽预约内存同步提高，固定内存下
+可并行槽位减少；若整片回填仍串行，增加工作粒度也可能只扩大尾延迟。
+`occupied = queue + active + results + leased` 的信用生命周期目前绑定全文消费，
+新架构需要明确窗口传播、全文后处理、顺序输出各自占哪些额度，不能靠增添一个
+线程池后无界囤积缓冲或让后处理等待占满的槽位。
+
+## 8. 测量和项目推进为何像在绕圈
+
+- 多轮优化是在同一串行链上节约百分之几，不能改变可并行工作占比。
+- 没有把“worker 实际采用字节”和“协调器解码字节”作为首要验收，原生覆盖率
+  和测试通过数容易掩盖任务图未变化。
+- 稳定性测试证明正确性，不能证明吞吐；已有约 200 项测试不等于并行目标达标。
+- 大部分新功能是默认关闭的 Rust 实验，公共 Python experimental 接口仍主要
+  是并行压缩/预取；没有把稳定的普通 gzip 内存/流式并行解压交付给 Python。
+- 跨轮基线差异明显，混合核调度和系统状态未完整控制；不能将不同报告的提升
+  相加，更不应持续增加自动阈值来拟合两个自造样本。
+
+本轮没有可靠 PMU 数据，尚不能确定具体缓存失效率、内存带宽利用率、逐函数
+指令成本或 Windows metadata 系统调用占比。应保留这些为待测问题，不能把
+“可能是内存带宽”作为已经找到的根因。
+文件读取每次仍有前后 metadata 检查，块边界和提交层也保留稳定性检查；它们
+属于下一步应计数/采样的外围成本，不能未经契约设计直接删掉。当前是 Discard
+输出，尚未包含写盘、全量输出缓存和 Python 业务消费造成的背压。
+
+## 9. 建议的后续实施顺序与停止条件
+
+先冻结当前实验组合，保留现有原生顺序路径作为实用基线，再按以下顺序验证：
+
+1. **独立符号内核原型。** 内存输入上连续解析多个 token，以任务输出为 LZ77
+   历史，按 match 保留额度检查，循环尾部处理补读/取消/错误。与当前符号路径
+   同输入差分，并分别测缓存输入与真实文件；未证明实质收益前不接入调度器。
+2. **两阶段片段状态。** 明确 CandidateDecoded、WindowResolved、Materialized、
+   Committed；精确位起点和可信尾窗链继续验证，窗口传播不等待全文回填。
+3. **有界并行后处理。** 取得真实前驱后，在共享有界池回填整个片段并算局部 CRC；
+   协调器只做尾窗传播、顺序 CRC 合并、member/framing 和最终输出事务。
+   局部 CRC 必须在 Marker 解析后计算，按 member 和真实长度合并。
+4. **粒度与信用一起调整。** 用实际片段输出/压缩比安排额度和检查点，避免输出
+   上限在网格中间频繁结束；保留大块、空块链、压缩炸弹与取消的硬边界。
+5. **固定验收矩阵。** 先控制同类物理核心，再测 Windows/UOS、公开日志/FASTQ/
+   二进制混合/随机/stored/重复输入，加入真实 bytes 输出而不仅是 Discard。
+
+每次只允许一个结构性变量，记录有效片段覆盖、重复量、符号吞吐、尾窗传播耗时、
+后处理耗时、协调器原生字节和峰值内存。不得以“平均任务占用”冒充硬件 CPU
+利用率；不得将提前准备索引的成绩包装为首次普通 gzip 解压。
+
+工具复现：
+
+```powershell
+$env:RUSTGZIP_BENCH_CPU = '0'
+python tools/audit_parallel_architecture.py
+python tools/audit_preindexed_native.py
+```
+
+第二个工具也会在每个测量进程内重新准备真实索引，但准备不计入报告的 seconds。
+本轮最终默认 debug 170 项、全开关 debug/release 各 200 项通过，各有两项测量
+默认跳过；严格 Clippy、格式检查和 Linux x86_64 tests 交叉检查通过。
+两个诊断工具实际运行了多个 release 配置，不把未执行的 ignored 测试记成通过。
+
+明确的通过标准应包括：在有足够可分块输入上，1→2→4 worker 有可重复扩展，
+日志四 worker 超过同轮顺序基线，正确性/内存/关闭契约保持，且真实输出路径
+仍有收益。达不到就停止向产品接口追加该方案，而不是再堆微优化阈值。

rustgzip-0.5.2/Cargo.lock

@@ -0,0 +1,42 @@
+# This file is automatically @generated by Cargo.
+# It is not intended for manual editing.
+version = 4
+
+[[package]]
+name = "cfg-if"
+version = "1.0.5"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "4e7648175b45a9a48536d676f68d918270699102aa8dab5496df06904c914600"
+
+[[package]]
+name = "crc32fast"
+version = "1.5.2"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "01a7799fd6b852db0e61728dde9a204c423b44d689dbd432522543614b490e78"
+dependencies = [
+ "cfg-if",
+]
+
+[[package]]
+name = "flate2"
+version = "1.1.10"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "6e634e2e0ebac1ee034020da1ca582e17ffe4e0f5e985823721e168928136dcb"
+dependencies = [
+ "crc32fast",
+ "zlib-rs",
+]
+
+[[package]]
+name = "rustgzip"
+version = "0.5.2"
+dependencies = [
+ "flate2",
+ "zlib-rs",
+]
+
+[[package]]
+name = "zlib-rs"
+version = "0.6.8"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "b268e58e7c693d7c271f93ffc4ba3b380412554231c85bf61ca7af91042a4112"

rustgzip-0.5.2/Cargo.toml

@@ -0,0 +1,42 @@
+[package]
+name = "rustgzip"
+version = "0.5.2"
+edition = "2021"
+license = "MIT"
+description = "Streaming gzip C ABI for Python 3.4 and newer"
+
+[lib]
+name = "rustgzip_native"
+crate-type = ["cdylib"]
+
+[dependencies]
+flate2 = { version = "=1.1.10", default-features = false, features = ["zlib-rs", "runtime_detection"] }
+zlib-rs = { version = "=0.6.8", default-features = false, features = ["std"] }
+
+[features]
+# 精确固定版本的底层恢复试验；默认不启用，不把 __internal-api 当作稳定接口承诺。
+known-window-backend = ["zlib-rs/__internal-api"]
+# 内部对照试验；统计构建有原子计数开销，不能用来报告正常吞吐。
+huffman-profile = []
+huffman-root9 = []
+huffman-root10 = []
+intrablock-handoff = ["known-window-backend"]
+history-feedback = ["intrablock-handoff"]
+# 在完整块边界交付有界未知前缀，后继仍由可信历史任务接续；默认关闭。
+unknown-prefix-yield = ["history-feedback"]
+direct-native-output = ["unknown-prefix-yield"]
+spare-native-output = ["direct-native-output"]
+# 协调器将已消费的真实历史缓冲用于下一块窗口快照，避免逐块分配/清零。
+reuse-native-history = ["known-window-backend"]
+# 连续原生块按需导出历史；需要候选验证/反馈时必须先取得真实窗口。
+lazy-native-history = ["coordinator-native", "reuse-native-history"]
+# 查询后没有排队任务时不广播唤醒空闲 worker；完成/关闭等通知不变。
+quiet-idle-workers = ["coordinator-native"]
+# 可信后继不派发串行依赖任务；协调器保留原生状态并推进，推测任务仍并行。
+coordinator-native = ["unknown-prefix-yield"]
+distance-bounded-handoff = ["intrablock-handoff"]
+
+[profile.release]
+lto = "thin"
+codegen-units = 1
+strip = "debuginfo"

rustgzip-0.5.2/ELF-AUDIT.txt

@@ -0,0 +1,79 @@
+
+Dynamic section at offset 0x82588 contains 30 entries:
+  Tag        Type                         Name/Value
+ 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
+ 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
+ 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
+ 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
+ 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
+ 0x000000000000001e (FLAGS)              BIND_NOW
+ 0x000000006ffffffb (FLAGS_1)            Flags: NOW
+ 0x0000000000000007 (RELA)               0x1170
+ 0x0000000000000008 (RELASZ)             24120 (bytes)
+ 0x0000000000000009 (RELAENT)            24 (bytes)
+ 0x000000006ffffff9 (RELACOUNT)          937
+ 0x0000000000000017 (JMPREL)             0x6fa8
+ 0x0000000000000002 (PLTRELSZ)           120 (bytes)
+ 0x0000000000000003 (PLTGOT)             0x85070
+ 0x0000000000000014 (PLTREL)             RELA
+ 0x0000000000000006 (SYMTAB)             0x2d0
+ 0x000000000000000b (SYMENT)             24 (bytes)
+ 0x0000000000000005 (STRTAB)             0xc9c
+ 0x000000000000000a (STRSZ)              1233 (bytes)
+ 0x000000006ffffef5 (GNU_HASH)           0xc30
+ 0x0000000000000019 (INIT_ARRAY)         0x801c8
+ 0x000000000000001b (INIT_ARRAYSZ)       16 (bytes)
+ 0x000000000000001a (FINI_ARRAY)         0x801c0
+ 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
+ 0x000000000000000c (INIT)               0x2006c
+ 0x000000000000000d (FINI)               0x20084
+ 0x000000006ffffff0 (VERSYM)             0xa50
+ 0x000000006ffffffe (VERNEED)            0xaf0
+ 0x000000006fffffff (VERNEEDNUM)         5
+ 0x0000000000000000 (NULL)               0x0
+
+Version symbols section '.gnu.version' contains 80 entries:
+ Addr: 0000000000000a50  Offset: 0x000a50  Link: 2 (.dynsym)
+  000:   0 (*local*)       0 (*local*)       0 (*local*)       0 (*local*)    
+  004:   2 (GLIBC_2.2.5)   3 (GLIBC_2.14)    2 (GLIBC_2.2.5)   4 (GCC_3.0)    
+  008:   2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)
+  00c:   2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)
+  010:   4 (GCC_3.0)       4 (GCC_3.0)       5 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)
+  014:   5 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   6 (GLIBC_2.3)  
+  018:   5 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)
+  01c:   5 (GLIBC_2.2.5)   0 (*local*)       4 (GCC_3.0)       4 (GCC_3.0)    
+  020:   4 (GCC_3.0)       2 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)
+  024:   5 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)
+  028:   7 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)
+  02c:   5 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   8 (GLIBC_2.3)     9 (GLIBC_2.28) 
+  030:   2 (GLIBC_2.2.5)   a (GLIBC_2.25)    2 (GLIBC_2.2.5)   b (GLIBC_2.18) 
+  034:   2 (GLIBC_2.2.5)   c (GLIBC_2.12)    d (GCC_3.3)       2 (GLIBC_2.2.5)
+  038:   5 (GLIBC_2.2.5)   e (GLIBC_2.16)    2 (GLIBC_2.2.5)   5 (GLIBC_2.2.5)
+  03c:   f (GLIBC_2.3.4)   4 (GCC_3.0)      10 (GCC_4.2.0)     4 (GCC_3.0)    
+  040:   4 (GCC_3.0)       4 (GCC_3.0)       2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)
+  044:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)   
+  048:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)   
+  04c:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)   
+
+Version needs section '.gnu.version_r' contains 5 entries:
+ Addr: 0x0000000000000af0  Offset: 0x000af0  Link: 6 (.dynstr)
+  000000: Version: 1  File: libgcc_s.so.1  Cnt: 3
+  0x0050:   Name: GCC_3.0  Flags: none  Version: 4
+  0x0060:   Name: GCC_3.3  Flags: none  Version: 13
+  0x0070:   Name: GCC_4.2.0  Flags: none  Version: 16
+  0x0010: Version: 1  File: libpthread.so.0  Cnt: 2
+  0x0080:   Name: GLIBC_2.2.5  Flags: none  Version: 5
+  0x0090:   Name: GLIBC_2.12  Flags: none  Version: 12
+  0x0020: Version: 1  File: libdl.so.2  Cnt: 1
+  0x00a0:   Name: GLIBC_2.2.5  Flags: none  Version: 7
+  0x0030: Version: 1  File: libc.so.6  Cnt: 8
+  0x00b0:   Name: GLIBC_2.2.5  Flags: none  Version: 2
+  0x00c0:   Name: GLIBC_2.3  Flags: none  Version: 8
+  0x00d0:   Name: GLIBC_2.3.4  Flags: none  Version: 15
+  0x00e0:   Name: GLIBC_2.14  Flags: none  Version: 3
+  0x00f0:   Name: GLIBC_2.16  Flags: none  Version: 14
+  0x0100:   Name: GLIBC_2.18  Flags: WEAK  Version: 11
+  0x0110:   Name: GLIBC_2.25  Flags: WEAK  Version: 10
+  0x0120:   Name: GLIBC_2.28  Flags: WEAK  Version: 9
+  0x0040: Version: 1  File: ld-linux-x86-64.so.2  Cnt: 1
+  0x0130:   Name: GLIBC_2.3  Flags: none  Version: 6

rustgzip-0.5.2/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 rustgzip-uos contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

rustgzip-0.5.2/MANIFEST.in

@@ -0,0 +1,16 @@
+include Cargo.toml Cargo.lock LICENSE README.md PROVENANCE.md
+recursive-include src *.rs
+recursive-include tests *.py
+recursive-include tools *.py
+recursive-include THIRD_PARTY_LICENSES *
+recursive-include vendor *
+include .cargo/config.toml
+include benchmark*.json tests*.log ELF-AUDIT.txt
+include UPSTREAM-REVIEW.md compare-*.json optimization-comparison.json
+include OPTIMIZATION-030.md buffer-sweep-*.json members-*.json optimization-030-comparison.json
+include REVIEW-031.md
+include PARALLEL-040.md parallel-*.json
+include OPTIMIZATION-050.md
+include REVIEW-051.md memory-051-comparison.json
+include RELEASE-052.md STAGED-FIRSTPASS-REPORT.md TWO-STAGE-POSTPROCESS-REPORT.md
+include SYMBOL-KERNEL-PROTOTYPE-REPORT.md ARCHITECTURE-BOTTLENECK-AUDIT.md

rustgzip-0.5.2/OPTIMIZATION-030.md

@@ -0,0 +1,82 @@
+# 0.3.0：继续搜索后的优化与验证
+
+本轮目标是减少已有解码路径的额外工作，兼容 Python 3.4，继续完整验证 gzip。
+新增封装独立编写，没有复制非公开代码，没有引入新的压缩算法或更改 gzip 格式。
+
+## 1. 搜索结果与采用理由
+
+- [flate2 Decompress API](https://docs.rs/flate2/1.1.10/flate2/struct.Decompress.html) 提供
+  gzip、未初始化输出及 Vec 剩余容量接口，可避免“临时缓冲 → 完整 Vec”的复制。
+  但查看锁定的 flate2 1.1.10 源码发现：其 zlib-rs 后端没有覆盖默认的
+  `decompress_uninit`，默认实现会先初始化整个输出区域。仅调用这个名字并不能获得预期收益。
+- [zlib-rs](https://github.com/trifectatechfoundation/zlib-rs) 的公开 `Inflate::decompress_uninit`
+  真正支持未初始化目标。本包此前已经通过 flate2 使用 zlib-rs 0.6.8；现在将同一版本
+  增加为直接依赖，用于内存快路径，没有增加新的第三方代码或许可证种类。
+- 同时核对 flate2 的 `crc.rs`，确认启用 zlib-rs 时本来就使用 zlib-rs 优化 CRC。
+  因此不能把“替换 CRC”当作已经实现的新加速。
+- [libdeflate 官方说明](https://github.com/ebiggers/libdeflate#api) 明确主要支持整块缓冲，
+  不支持普通流式接口；不能直接替代我们的大文件 open/verify。保留为未来独立后端的候选。
+- [zenflate 许可](https://github.com/imazen/zenflate#license) 是 AGPL/商业双许可。
+  本次没有集成它，不改变现有包的宽松许可依赖集合。
+
+## 2. 已保留的改动
+
+### 内存路径直接填充 Vec 剩余容量
+
+新增 `src/memory.rs`。常见的无可选字段 gzip 头交给 zlib-rs gzip 模式，
+CRC、ISIZE、DEFLATE 和结束状态仍由公开后端检查。用后端报告的已写入字节数扩展 Vec.len，
+未写入的容量不返回 Python。所有指针/容量均继续配对释放。
+
+遇到 FNAME、FCOMMENT、FEXTRA、FHCRC 或异常标志时，余下串接流转交原有 flate2 解析路径，
+保留字段长度限制、保留位检查、头部 CRC 和错误行为。缓冲区尾部也不因回退而被清零。
+
+当结果恰好填满 Vec 时，先用一个栈字节探测 EOF/CRC，不为了确认结束而先扩容整个结果。
+确实还有数据才扩大容量，输出仍受 max_output_size 限制。gzip ISIZE 继续只作为有界提示。
+
+### 串接文件复用解码状态
+
+原来每结束一个 member 就销毁、重新创建 GzDecoder。现在通过输入槽位和公开 reset 接口
+复用状态，保留未消费的压缩输入。CRC、位流、窗口有效长度和解析状态均重置。
+适合由许多小 member 组成的 gzip。文件流不改为整文件加载。
+
+## 3. 没有保留为默认行为的尝试
+
+扫描了 verify 的 16/32/64/128/256/512/1024/2048 KiB 缓冲大小。
+没有找到两个平台、不同数据都获益的默认值，因此继续保持 1 MiB。
+较小缓冲在构建虚拟机上反而可能显著变慢。完整结果见 buffer-sweep-*.json。
+
+没有默认开启预取线程、强制 AVX2/AVX512 或改变压缩级别；没有跳过 CRC。
+普通单流 gzip 多核解压尚未实现，不能把 member 状态复用称为多核解码。
+
+## 4. 与 0.2.0 的比较方式和限制
+
+同平台使用相同输入，通过 SHA256 对齐；独立进程加载各自动态库，预热后测七轮取中位数。
+最终新旧版本串行执行，不同时运行两套性能测试。操作系统文件缓存仍参与文件测试。
+真实内网 UOS 没有实测，Linux 结果来自 Debian 10 / Python 3.4.10 构建虚拟机。
+
+Linux 最后一次 16 MiB 普通输入比较中，structured：20.986 → 19.055 ms（1.10 倍）；random：10.307 → 5.905 ms（1.75 倍）。
+此前复测曾得到约 1.06/1.37 倍，结果受负载、缓存和分配器影响。
+小输入和 decompress_into 不是所有项目都有收益，不宣称普遍加速。
+
+串接 member 文件测试（总原始数据 16 MiB）：
+
+| member 大小 | 操作 | 0.2.0 | 0.3.0 | 比值 |
+|---|---|---:|---:|---:|
+| 4 KiB，4096 个 | verify | 106.219 ms | 77.710 ms | 1.37 倍 |
+| 4 KiB，4096 个 | file_read | 125.424 ms | 111.137 ms | 1.13 倍 |
+| 64 KiB，256 个 | verify | 11.422 ms | 10.197 ms | 1.12 倍 |
+| 64 KiB，256 个 | file_read | 14.266 ms | 12.952 ms | 1.10 倍 |
+
+初轮串接 verify 测试曾只有约 0～2% 变化，因此也不把最终 37% 样例推广为普遍收益。
+单 member 的 open/verify 基本没有本质变化；压缩路径本轮未优化，不能将其计时变化算作收益。
+Windows 多次测试出现明显的环境速度波动，连未改动的压缩/verify 也变化很大，
+因此不把这一轮 Windows 数字作为可靠加速结论。原始样本仍保留供检查。
+
+## 5. 正确性与交付
+
+Linux Python 3.4.10/3.7 均通过 69 项测试；Windows 通过 68 项并跳过 1 项 Linux 专用测试。
+测试包含 80 组随机输出/容量边界、空 member、千个串接 member、padding、头部 CRC、
+最后 member 损坏、截断、跨 member 字典隔离、输出尾部保持及磁盘写满。
+
+Rust clippy 严格警告检查通过。ABI 标记升级为 3，用于拒绝混装旧动态库和新版 Python。
+Python API 用法保持兼容；升级时替换整个 wheel/包，运行时仍无第三方 Python 依赖。