Benchmarks

There are two separate benchmark setups with different purposes:

Continuous benchmark — source and results at https://github.com/ringsaturn/tz-benchmark, visualized at https://ringsaturn.github.io/tz-benchmark/. Runs automatically in GitHub Actions on each release for cross-package comparison. Because GitHub Actions runners have different hardware than a developer machine, the absolute numbers differ from local runs, but the relative trends between packages are what matters here. The dated snapshots under snapshot/ are a separate thing: those are captured locally on the same Apple M3 Max as the tables below, so their absolute numbers are directly comparable to this page.

Local benchmark — the tables below were measured on an Apple MacBook Pro with Apple M3 Max. These give a more representative picture of real-world latency on modern hardware.

Methodology

Each finder is initialized once and reused for all queries, matching the recommended production pattern. Queries use a representative sample of global city coordinates plus intentional edge-case border points.

Two different notions of memory appear below, and they are not interchangeable. The Go tables report retained memory — what the finder still holds once it is ready to serve queries. The Rust and Python tables report peak RSS — the high-water mark reached while loading, which is several times larger because building a finder decodes the whole .pb dataset into an intermediate representation before discarding it, and freeing memory does not return the pages to the kernel. Do not read a Go figure and a Rust figure as the same measurement. SeeHow much memory does tzf use? for both figures measured side by side on the same runs.

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 is a PyO3 binding over tzf-rs. The benchmark uses pytest-benchmark and measures a single get_tz() call (random coordinate, topology-simplified dataset). Results from Apple MacBook Pro with Apple M3 Max.

Per-call overhead is comparable to the raw Rust figures; the difference from tzf-rs numbers reflects the Python → Rust FFI cost via PyO3.

Key observations

• YStripes substantially reduces polygon lookup latency. For Rust Finder, the full-precision median falls from 43.0520 µs to 1.2227 µs, a 35.2× speedup. On the topology-simplified dataset it falls from 4.9164 µs to 0.5698 µs, an 8.6× speedup.
• DefaultFinder is the strongest general-purpose Rust option. Its median is 0.3040 µs on topology-simplified data and 0.5527 µs on full-precision data. The preindex adds about 9 to 12 MiB of init peak RSS over the corresponding YStripes-enabled Finder.
• FuzzyFinder is useful as a fast path with a fallback. A miss completes in 0.1564 µs, while DefaultFinder resolves the same edge-city workload through its YStripes fallback in 0.6256 µs. Standalone use remains suitable only when queries are known to stay away from timezone borders.
• Python benefits significantly from YStripes. The tzfpy median falls from 1.6410 µs to 0.6533 µs, and throughput rises from 604.3 to 1490.1 Kops/s, about 2.5×.
• Full-precision data has a clear memory cost. With YStripes enabled, moving from topology-simplified to full-precision data adds about 241 to 245 MiB of init peak RSS in Rust. In Go, retained memory rises from about 30 MiB to about 153 to 155 MiB. These are the two different bases described in Methodology, so the Rust and Go increases are not directly comparable.
• Init peak is not what tzf costs to keep running. The Rust peak RSS figures above overstate steady state by roughly 2× to 3×: in the 2026-07-26 snapshot, measured on the same machine, DefaultFinder on topology-simplified data peaks at 77.0 MiB while retaining 36.3 MiB, and Finder peaks at 48.0 MiB while retaining 20.7 MiB. Size a container for the peak; budget long-running cost from the retained figure.