理解 Qeltrix V1 PoC 性能：背景与局限

Source: Dev.to

关键背景：这个 PoC 实际上是什么

这是一份最基础层面的概念验证（Proof‑of‑Concept）。
它既不是预开发阶段，也不是原型，更不是 alpha 版软件。V1 PoC 仅用于回答一个问题：“这种技术方案可行吗？” 性能测量用于验证可行性，但它们并不代表已优化、可投入生产的性能。

PoC 定义

• 目的：验证核心概念的可行性
• 优化程度：无——刻意保持基础
• 代码成熟度：基础验证代码
• 性能目标：证明可行，而不是证明快速

为什么 V1 的性能数据本身就受限

1. Python 实现的限制

V1 PoC 使用 Python 编写，这会带来显著的性能开销：

• Python 的全局解释器锁（GIL）
  • 限制 CPU 密集型操作的真正并行执行
  • 同时只能有一个线程执行 Python 字节码
  • ProcessPoolExecutor 能有所帮助，但会增加进程间通信开销
• 解释型语言 vs. 编译型语言的速度差异
  • Python 通常 比 Rust、C、C++ 等编译语言慢 10–50 倍
  • 用系统语言实现的生产版本性能会截然不同
  • 同样的算法在 Rust 或 C++ 中轻易实现 10–20 倍更高的吞吐量

2. 测试环境的限制

使用硬件：预算笔记本
公开的结果来源于一台预算笔记本，而非专用测试服务器或高性能工作站。这会显著影响：

• 可用的 CPU 核心数和处理能力
• 内存带宽与缓存性能
• 磁盘 I/O 速度
• 整体散热管理

操作系统：Windows

• 与 Linux 相比，Windows 会带来额外的开销
• 后台服务和系统进程会消耗资源
• 文件 I/O 性能与类 Unix 系统不同

并发系统负载

测试环境同时运行许多其他服务和应用（后台系统服务、开发工具、网页浏览器、系统监控、杀毒软件），导致可用系统资源在测试期间被削减。

3. PoC 设计的限制

• 没有进行任何优化
  • 代码优先保证可读性和概念验证，而非性能
  • 未进行任何剖析或性能调优
  • 算法采用直接实现，而非优化变体
  • 内存分配和数据结构都很基础
• 单线程解包
  • V1 只在打包阶段实现了并行处理，解包阶段是顺序执行的，这在实际双向使用场景中会显著限制吞吐量。

这些数字到底意味着什么

高度可压缩文本：44.8 MB/s

最佳情况，满足以下条件：

• 数据压缩率极高（压缩率 99.57 %）
• 并行打包提供最大收益
• 系统未受到 I/O 瓶颈限制

现实检查：在优化硬件和生产实现上，这一数字轻易可以达到 500+ MB/s。

低可压缩性二进制：1.8 MB/s

two_pass 模式的最差情况，满足以下条件：

• 数据几乎不压缩（保持 100 % 比例）
• 系统必须处理完整文件以进行密钥派生
• Python 的开销最为明显

现实检查：使用编译实现，同样的操作可以达到 50–100+ MB/s。

single_pass_firstN 模式：17.5 MB/s

展示了当密钥派生不需要完整文件处理时的架构灵活性和性能提升。

现实检查：仍受 Python 限制。使用生产语言预计可提升 10–20×。

真正的性能故事

我们实际在测试什么

• 架构可行性 – 并行处理 + 流式 + 加密能否协同工作？
• 加密正确性 – 输出是否达到合适的熵值（约 8.0 bits/byte）？
• 实现完整性 – 能否处理各种文件类型和大小？

我们 不 在测试什么

• 优化后的性能 – 对 PoC 来说明确超出范围
• 生产就绪度 – 代码仅用于基础验证
• 竞争性基准 – 将 PoC Python 与生产工具对比毫无意义

呼吁社区测试

我们需要你的帮助来获取真实世界的性能数据。
由于公开结果仅来源于单台预算笔记本，它们并不能完整反映全貌。我们鼓励社区：

在你的环境中运行测试

git clone https://github.com/Qeltrix/test-poc-1.git
cd test-poc-1
python test_qeltrix.py

• 将你的结果连同硬件规格一起分享。

多样化的测试场景

• 不同操作系统（Linux、macOS、Windows）
• 各类硬件配置（工作站、服务器、其他笔记本）
• 不同系统负载（专用测试 vs. 正常使用）
• 各种存储介质（SSD、NVMe、HDD）

我们将学到什么

• 各环境间的性能差异
• 各配置下的瓶颈定位
• 对未来优化的现实基线预期
• 基于数据的 V2 及以后版本的优先级

展望：生产实现的潜力

预期改进

保守估计

一个生产就绪的 Qeltrix 实现现实上可以达到：

• 高度可压缩数据：500–2000 MB/s
• 混合数据：200–800 MB/s
• 低可压缩性数据：100–500 MB/s

假设使用现代硬件（8+ 核心、NVMe SSD）以及生产质量代码。

为什么性能对 PoC 也重要

• 基线建立 – 知道起点，以便衡量进展。
• 瓶颈识别 – 基础指标能揭示架构限制。
• 可行性验证 – 证明系统能够以可用速度处理真实数据。
• 设计验证 – 模式对比（two_pass vs. single_pass_firstN）为架构决策提供依据。

结论：请合理设定期望

如果你在评估 Qeltrix V1 PoC：

• 不要把这些数字和生产工具直接比较。
• 不要期望 PoC 代码已经实现了优化性能。
• 不要把 Python 的性能当作概念潜力的代表。
• 不要仅凭单一环境的测试结果来判断架构。

相反：

• 认识到这已经验证了技术方案可行。
• 感谢对局限性的透明披露。
• 考虑贡献你所在环境的测试数据。
• 明白还有巨大的性能提升空间。
• 专注于已被证明的架构基础。

V1 PoC 已实现其目标：证明 Qeltrix 的核心概念在技术上是可行的。虽然性能数字受 Python 与测试环境限制，但即便在最差实现下，系统也能正确运行并处理真实数据。

真正的性能故事将在社区用生产语言构建优化实现时书写。

参与进来

帮助我们收集真实的性能数据：

• 测试仓库：