All values come from x86_64/performance-comparison-data/summary.json. Speedup = After / Before median throughput; change = (speedup − 1) × 100; latency reduction = (1 − After / Before) × 100. Hover or focus any bar, candle or cell for exact values; every value is also in the tables below.

All values come from aarch64/performance-comparison-data/summary.json. Speedup = After / Before median throughput; change = (speedup − 1) × 100; latency reduction = (1 − After / Before) × 100. Hover or focus any bar, candle or cell for exact values; every value is also in the tables below.

Throughput at 10M queries

Total work is fixed: 1 worker performs 10,000,000 lookups, 2 workers 5,000,000 each.

Latency distribution

Separate latency campaign: one actual operation in every 16 is timed individually; workers are merged and repetitions pooled before percentiles are computed. Lower whisker min → p50, body p50 → p95, upper whisker p95 → p99, ◆ p50; the maximum is listed at the right of each row and in tooltips.

Thread scaling

Scaling = throughput(N) / throughput(1) of the same version; parallel efficiency = scaling / N × 100. Configurations that scale above 100% do so because the measured core cycles per lookup of each worker drop as workers are added (see the chart footers); the cause was not isolated.

Memory

Measured in fresh processes with the same preparation and warm-up as the throughput campaign. Process RSS is a whole-process metric; the library heap (mallinfo2 in-use bytes after MMDB_open) isolates reader and index allocations.

Startup and index preparation

After builds its native child array and 65,536-entry root tables inside MMDB_open; MMDB_NO_PREPARE skips that work. Opening time is measured separately from steady-state lookups.

Allocations

Every throughput configuration

Attribution between the traversal changes

A separate three-way campaign isolates the specialized packed traversal (After opened with MMDB_NO_PREPARE) from the automatic radix-16/native preparation, on identical corpora with 5 repetitions per variant in rotating order. Ratios are medians with 95% bootstrap intervals.

Result tables

Rows follow the filters above unless “show every configuration” is checked. Click a column header to sort.

Throughput

Latency (pooled sampled percentiles)

Memory

Startup

Allocations

Hardware and methodology

Workloads and correctness

Validation: checksums identical across versions and repetitions: True · completed counts and zero errors: True · corpora identical between versions: True · ordered per-query differential digests identical on 8 corpora: True.

Limitations

• Throughput covers IPv4 and IPv6, random addresses, lookup and lookup + decode, 10M queries, 1 and 2 threads on GeoLite2-City; latency covers IPv4 and IPv6, random addresses, lookup, 10M queries, 1 and 2 threads, with 5 repetitions per version and configuration. The Synthetic mixed fixture and populated-network workloads only enter the differential, memory, startup and allocation measurements.
• GitHub-hosted runner: a virtual machine on shared cloud hardware, not an isolated benchmark host. Other tenants of the physical host and the runner's own processes kept running (largest mean consumers: Runner.Worker (0%), provjobd4117846 (0%), python3 (0%), Runner.Listener (0%), hv_kvp_daemon (0%)), and the guest's core topology need not match the physical one. Alternating order, per-repetition warm-up and 5 repetitions limit, but do not remove, their effect; 2-worker runs occupy every physical core and are the most exposed.
• SMT stays enabled. CPU frequency is not visible from this machine (no cpufreq interface). Single-thread results run on the first allowed CPU.
• Latency percentiles describe sampled operations (one in sixteen) and include the timer-read overhead; the maximum is the largest sampled value, not of every lookup.
• GeoLite2-City is a real database (build 2026-10-30) that cannot be redistributed; the synthetic fixture is reproducible from benchmarks/harness/generate_synthetic_database.py but is not representative of commercial databases.
• Uniformly random IPv6 addresses almost never match GeoLite2-City, so random IPv6 results mostly measure misses.
• Results are specific to this x86-64 CPU, compiler and memory hierarchy; this report has no AArch64 or 32-bit measurements.
• Some configurations show parallel efficiency above 100%: APERF cycles per lookup per worker decrease with more workers. The mechanism (for example memory and fabric power management at low load) was not isolated.
• Cache-miss and branch-miss counters were unavailable; cycles per lookup come from APERF and include any interference on the pinned CPU.
• The TSC-backed clock advances in steps of about 10 ns on this CPU (98.0% of latency samples fall on a 10 ns grid), so sub-50 ns latency percentiles are coarse.

Reproduction

# From the repository root. Needs Linux, GCC, Clang, CMake + Ninja, Autotools, OpenSSL headers,
# Python 3.11+, Node.js and Chrome. Builds both revisions, runs every campaign and the test suites, then
# regenerates benchmarks/reports; the measurements took 5 min on the machine above.
benchmarks/reproduce.sh /path/to/GeoLite2-City.mmdb   # build 2026-10-30, SHA-256 9e52c481…9d5563
# GitHub Actions measures x86-64 and AArch64 runners for every pushed benchmarks/* branch
# (.github/workflows/benchmarks.yml); this report comes from run 41200090568.

Exported figures

• throughput-ipv4-10m.png · SVG — IPv4 Throughput — Random Lookups (10M)
• throughput-ipv6-10m.png · SVG — IPv6 Throughput — Random Lookups (10M)
• candlestick-ipv4-10m.png · SVG — Candlestick Percentile Rank — IPv4 Lookups (10M)
• candlestick-ipv6-10m.png · SVG — Candlestick Percentile Rank — IPv6 Lookups (10M)
• memory-usage.png · SVG — Memory Usage — Reader State and Process RSS
• startup-time.png · SVG — Startup — Database Opening and Index Preparation
• thread-scaling.png · SVG — Thread Scaling — Random Lookups
• allocations.png · SVG — Heap Allocations per Lookup + Field Decode
• radix16-preparation.png · SVG — Radix-16 Preparation and Lookup
• speedup-matrix-city.png · SVG — Throughput Speedup Matrix — GeoLite2-City

Throughput at 10M queries

Total work is fixed: 1 worker performs 10,000,000 lookups, 2 workers 5,000,000 each, 4 workers 2,500,000 each.

Latency distribution

Separate latency campaign: one actual operation in every 16 is timed individually; workers are merged and repetitions pooled before percentiles are computed. Lower whisker min → p50, body p50 → p95, upper whisker p95 → p99, ◆ p50; the maximum is listed at the right of each row and in tooltips.

Thread scaling

Scaling = throughput(N) / throughput(1) of the same version; parallel efficiency = scaling / N × 100. Configurations that scale above 100% do so because the measured core cycles per lookup of each worker drop as workers are added (see the chart footers); the cause was not isolated.

Memory

Measured in fresh processes with the same preparation and warm-up as the throughput campaign. Process RSS is a whole-process metric; the library heap (mallinfo2 in-use bytes after MMDB_open) isolates reader and index allocations.

Startup and index preparation

After builds its native child array and 65,536-entry root tables inside MMDB_open; MMDB_NO_PREPARE skips that work. Opening time is measured separately from steady-state lookups.

Allocations

Every throughput configuration

Attribution between the traversal changes

A separate three-way campaign isolates the specialized packed traversal (After opened with MMDB_NO_PREPARE) from the automatic radix-16/native preparation, on identical corpora with 5 repetitions per variant in rotating order. Ratios are medians with 95% bootstrap intervals.

Result tables

Rows follow the filters above unless “show every configuration” is checked. Click a column header to sort.

Throughput

Latency (pooled sampled percentiles)

Memory

Startup

Allocations

Hardware and methodology

Workloads and correctness

Validation: checksums identical across versions and repetitions: True · completed counts and zero errors: True · corpora identical between versions: True · ordered per-query differential digests identical on 8 corpora: True.

Limitations

• Throughput covers IPv4 and IPv6, random addresses, lookup and lookup + decode, 10M queries, 1, 2 and 4 threads on GeoLite2-City; latency covers IPv4 and IPv6, random addresses, lookup, 10M queries, 1, 2 and 4 threads, with 5 repetitions per version and configuration. The Synthetic mixed fixture and populated-network workloads only enter the differential, memory, startup and allocation measurements.
• GitHub-hosted runner: a virtual machine on shared cloud hardware, not an isolated benchmark host. Other tenants of the physical host and the runner's own processes kept running (largest mean consumers: Runner.Worker (0%), python3 (0%), provjobd1004205 (0%), containerd (0%), Runner.Listener (0%)), and the guest's core topology need not match the physical one. Alternating order, per-repetition warm-up and 5 repetitions limit, but do not remove, their effect; 4-worker runs occupy every physical core and are the most exposed.
• CPU frequency is not visible from this machine (no cpufreq interface). Single-thread results run on the first allowed CPU.
• Latency percentiles describe sampled operations (one in sixteen) and include the timer-read overhead; the maximum is the largest sampled value, not of every lookup.
• GeoLite2-City is a real database (build 2026-10-30) that cannot be redistributed; the synthetic fixture is reproducible from benchmarks/harness/generate_synthetic_database.py but is not representative of commercial databases.
• Uniformly random IPv6 addresses almost never match GeoLite2-City, so random IPv6 results mostly measure misses.
• Results are specific to this AArch64 CPU, compiler and memory hierarchy; this report has no x86-64 or 32-bit measurements.
• Some configurations show parallel efficiency above 100%. The mechanism was not isolated; no cycle counter was available to check whether per-lookup cost changes with the number of workers.
• Cycle, cache-miss and branch-miss counters were unavailable; only wall-clock and thread CPU time were measured.
• The Arm generic timer advances in steps of about 8 ns on this CPU (100.0% of latency samples fall on a 8 ns grid), so sub-40 ns latency percentiles are coarse.

Reproduction

# From the repository root. Needs Linux, GCC, Clang, CMake + Ninja, Autotools, OpenSSL headers,
# Python 3.11+, Node.js and Chrome. Builds both revisions, runs every campaign and the test suites, then
# regenerates benchmarks/reports; the measurements took 4 min on the machine above.
benchmarks/reproduce.sh /path/to/GeoLite2-City.mmdb   # build 2026-10-30, SHA-256 9e52c481…9d5563
# GitHub Actions measures x86-64 and AArch64 runners for every pushed benchmarks/* branch
# (.github/workflows/benchmarks.yml); this report comes from run 41200090568.

Exported figures

• throughput-ipv4-10m.png · SVG — IPv4 Throughput — Random Lookups (10M)
• throughput-ipv6-10m.png · SVG — IPv6 Throughput — Random Lookups (10M)
• candlestick-ipv4-10m.png · SVG — Candlestick Percentile Rank — IPv4 Lookups (10M)
• candlestick-ipv6-10m.png · SVG — Candlestick Percentile Rank — IPv6 Lookups (10M)
• memory-usage.png · SVG — Memory Usage — Reader State and Process RSS
• startup-time.png · SVG — Startup — Database Opening and Index Preparation
• thread-scaling.png · SVG — Thread Scaling — Random Lookups
• allocations.png · SVG — Heap Allocations per Lookup + Field Decode
• radix16-preparation.png · SVG — Radix-16 Preparation and Lookup
• speedup-matrix-city.png · SVG — Throughput Speedup Matrix — GeoLite2-City