基准测试

项目有两套独立的基准测试，用途不同：

持续基准测试：源代码及结果位于 https://github.com/ringsaturn/tz-benchmark， 可视化展示在 https://ringsaturn.github.io/tz-benchmark/。每次发布时在 GitHub Actions 中自动运行，用于跨包对比。由于 GitHub Actions 运行器与开发者机器硬件不同，绝对数值与本地运行有所差异，但包之间的相对趋势可以说明问题。仓库中 snapshot/ 目录下按日期归档的快照则是另一回事： 那些是在与下表相同的 Apple M3 Max 上本机跑出来的，绝对数值可以与本页直接对比。

本地基准测试：以下表格在搭载 Apple M3 Max 的 MacBook Pro 上测得。这些结果更能反映现代硬件上真实场景的延迟。

测试方法

每个查找器初始化一次并复用于所有查询，匹配推荐的生产环境模式。查询使用全球城市坐标的代表性样本加上特意选取的边界边缘案例点。

下面出现了两种不同口径的内存数据，二者不可互换。 Go 表格给出的是常驻内存——查找器准备好接受查询后仍然持有的部分； Rust 和 Python 表格给出的是峰值 RSS——加载过程中达到的高水位。后者要大好几倍，因为构建查找器时会先把整个 .pb 数据集解码成中间表示再丢弃， 而释放内存并不会把页面归还给内核。不要把 Go 的数字和 Rust 的数字当作同一种测量来读。两种口径在同一批测量中的并排对比，参见tzf 使用多少内存？。

Go (tzf v1.2.3)

Rust (tzf-rs v1.3.6)

Topology-Simplified (bundled) / Random Cities

Topology-Simplified (bundled) / Edge Cities (FuzzyFinder misses)

Full-Precision (full)

Python (tzfpy v1.3.2)

tzfpy 是基于 tzf-rs 的 PyO3 绑定。基准测试使用 pytest-benchmark 测量单次 get_tz() 调用（随机坐标，拓扑简化数据集）。结果来自搭载 Apple M3 Max 的 MacBook Pro。

每次调用开销与原始 Rust 数据相当。与 tzf-rs 数据的差异反映了通过 PyO3 的 Python → Rust FFI 开销。

关键结论

• YStripes 可显著降低多边形查询延迟。Rust Finder 使用完整精度数据时，中位延迟从 43.0520 µs 降至 1.2227 µs，速度提升 35.2 倍。使用拓扑简化数据时，中位延迟从 4.9164 µs 降至 0.5698 µs，速度提升 8.6 倍。
• DefaultFinder 是 Rust 通用场景的最佳选择。拓扑简化数据的中位延迟为 0.3040 µs，完整精度数据为 0.5527 µs。与启用 YStripes 的对应 Finder 相比，预索引增加约 9 到 12 MiB 初始化峰值 RSS。
• FuzzyFinder 适合作为配有回退机制的快速路径。查询未命中时耗时 0.1564 µs，DefaultFinder 通过 YStripes 回退处理相同的边界城市工作负载时耗时 0.6256 µs。仅当查询坐标确定远离时区边界时，才适合单独使用 FuzzyFinder。
• Python 同样能从 YStripes 中显著受益。tzfpy 的中位延迟从 1.6410 µs 降至 0.6533 µs，吞吐量从 604.3 Kops/s 提升至 1490.1 Kops/s，约为原来的 2.5 倍。
• 完整精度数据会增加内存开销。启用 YStripes 时，从拓扑简化数据切换到完整精度数据会使 Rust 初始化峰值 RSS 增加约 241 到 245 MiB。在 Go 中，常驻内存从约 30 MiB 增至约 153 到 155 MiB。这两个数字属于测试方法中说明的两种不同口径，因此 Rust 与 Go 的增幅不能直接对比。
• 初始化峰值不等于 tzf 长期运行的成本。上面 Rust 的峰值 RSS 大约高估了稳定状态 2 到 3 倍：在同一台机器上测得的 2026-07-26 快照中，拓扑简化数据上的 DefaultFinder 峰值 77.0 MiB，常驻仅 36.3 MiB；Finder 峰值 48.0 MiB，常驻 20.7 MiB。容器内存按峰值规划，长期运行成本按常驻值估算。