Rows of servers in an Elara-Cortex data hall

Elara-Cortex Technical Report · TR-2026-02 · 19 July 2026

Measured performance of a production routing engine: solution quality, incremental re-optimisation, and data-layer efficiency on real road graphs.

K. Lekola. Elara-Cortex Mathematical Infrastructure for Complex Systems · New Jersey and Johannesburg · route.elara-cortex.com

Abstract. We report the measured performance of the Elara production routing engine across five dimensions, with the strongest public tools run identically beside it on the same machine: (i) solution quality against Google OR-Tools on seeded multi-stop instances from 10 to 1 000 stops, where the engine reaches the proven optimum at the smallest instance tested (10 stops) and overtakes the baseline as size grows (−0.3% at 500 stops, −10.4% at 1 000; single-seed illustrative sweep, §8); (ii) incremental re-optimisation, where a route change is evaluated as a single update rather than a full recompute, giving 36.8–244.6× less work for a byte-identical result; (iii) memory footprint, serving 180 474 towns from a 1 GB production server against the open reference router's own published requirement of ~44 GB to run; (iv) delta transmission, resending only the changed portion of a route (80.1% saved on the measured case) with a cryptographic checksum verifying byte-exact reconstruction; and (v) data-layer efficiency, where lossless compression of a real 162 MB production log is 93% (smaller than gzip and Brotli on this corpus) and integrity checking runs at 30 GB/s on the same machine where xxHash reaches 21 GB/s. Every numerical figure on this page is emitted by the benchmark harness rather than transcribed by hand.

1 · Experimental protocol

Road graph. The live Johannesburg metropolitan graph: 388 386 nodes, 736 061 edges, served in production by the same host that serves this page.
Instances. Multi-stop problems on seeded random stops (deterministic; the seed is fixed so any reader reproduces the identical instance). Formal benchmark sets (CVRPLIB, Solomon, Gehring–Homberger) are treated separately in TR-2026-01.
Baseline. Google OR-Tools, run on the same machine with the same instances and time budgets. Comparison tools for the data layer (gzip, Brotli, xxHash, SHA-256) are invoked identically on the same inputs.
Reproduction. One command, python bench_pack.py, rebuilds every table on this page; python bench_field.py rebuilds the data-layer results. Every figure below is emitted by the harness, not transcribed.

2 · Solution quality against a widely used open-source solver (Google OR-Tools)

At 10 stops the engine returns the proven optimal tour. As instance size grows the gap to the baseline narrows, closes, and inverts: from 500 stops upward the engine returns strictly better routes than OR-Tools on the same instance and budget.

Figure 1. Solution quality relative to Google OR-Tools as problem size grows (single-seed sweep, §8). Positive = Elara slightly longer; negative = Elara shorter. The curve crosses zero near 500 stops: on large instances Elara returns strictly shorter routes than the baseline. Data: Table 1.

Table 1. Solve time and solution quality vs Google OR-Tools on seeded instances (single fixed seed per size; illustrative size sweep). Both solvers run to a comparable time budget on the same machine, OR-Tools with guided local search; negative = shorter route than the baseline.
Stops	Solve time	Improvement vs as-submitted order	Quality vs OR-Tools	Vs proven optimum
10	0.35 ms	−41.5%	optimal	0.0% (optimal)
25	1.7 ms	−70.5%	+9.7%	—
50	7.1 ms	−75.3%	+5.1%	—
100	29 ms	−83.8%	+1.5%	—
200	270 ms	−89.2%	+0.9%	—
500	3.1 s	−93.2%	−0.3%	—
1000	16.8 s	−95.2%	−10.4%	—

Across the sizes measured the advantage grows with instance size; this single-seed sweep is illustrative and the stricter, seeded-instance limitations are stated in §8. The same direction holds under the controlled protocol of the community benchmarks (TR-2026-01: ahead of OR-Tools on every CVRPLIB X-instance on which both solvers were run, and certified optimal 5 of 5 where an exact solver can certify the optimum).

3 · Incremental re-optimisation: one update, not one recompute

The engine evaluates a candidate route change as a single constant-cost update within its mathematical framework, rather than recomputing the route from scratch. The output is verified byte-identical to the full recomputation; only the work differs. The method itself is proprietary and is not disclosed (TR-2026-01 §2); the measurement is externally checkable.

Figure 2. Work saved by incremental re-optimisation versus a full recompute, for a byte-identical resulting route (log scale). The advantage grows with problem size, from 36.8× at 50 stops to 244.6× at 300. Data: Table 2.

Table 2. Incremental update vs naive full recompute; identical resulting routes verified per row.
Stops	Incremental update	Full recompute	Work ratio	Result identical
50	0.96 ms	35.4 ms	36.8×	yes
100	3.8 ms	362 ms	95.6×	yes
200	30 ms	3.49 s	115.7×	yes
300	78 ms	19.1 s	244.6×	yes

This property is what makes continuous re-planning affordable: for live fleet dispatch, drone corridors and autonomous routing, the operationally decisive cost is the cost of the next plan, not the first one (TR-2026-01 §7 proposes time-to-replan as a reporting standard).

3.1 · Memory footprint against a planet-scale baseline

The open reference router (OSRM) documents ~123 GiB to prepare the planet for car routing and ~44 GB of memory to run it. The Elara production service holds 180 474 towns on a 1 GB server, the same machine serving this page.

Table 3. Deployed memory footprint, each system for its own coverage. Elara serves a 180,474-town inter-town index in 1 GB; OSRM serves a full planet street-level graph (car profile) in ~44 GB. These are different coverage classes, not a like-for-like data structure; the ratio compares each system's deployed footprint. Baseline figures are the reference router's own published numbers.
System	Memory	Coverage	Ratio
Elara (live in production)	1 GB	180 474 towns	44× smaller footprint (different coverage class)
Open reference router (published)	~44 GB run · ~123 GiB prepare	planet, car profile	—

Baseline sources: the project's published requirements and runtime measurements.

4 · Delta transmission with cryptographic verification

When a road closes mid-route, the service transmits only the changed portion of the path together with a SHA-256 checksum, so the receiving device proves it reconstructed the route byte-for-byte.

Table 4. Measured delta transmission on a mid-route road closure.
Route	Changed	Full re-send	Delta sent	Saved	Verified
228 points	18 points	935 B	186 B	80.1%	SHA-256

4.1 · Re-solve avoidance under continuous cost change

Under live traffic, edge costs change every second. The engine classifies each change against the active route and re-solves only when the change can affect it; in the measured workload 97% of changes require no re-solve at all.

Table 5. Per-change rerouting cost under continuous cost updates.
Metric	Elara (incremental)	Elara (full re-solve, same engine)	Ratio
Cost per traffic-change reroute	0.0037 ms	1.1185 ms	302× less
Changes requiring no full re-solve	97%	0% (always re-solves)	97% skipped

5 · Latency on the live metropolitan graph

Shortest-time routing on the production Johannesburg graph, computed on the serving host with no external round-trip:

Table 6. Route latency on the live 388 386-node metro graph.
Route	Distance	Cold solve	Cached
Short	5.2 km	29 ms	16 ms
Medium	16.0 km	49 ms	18 ms
Long, cross-metro	37.7 km	723 ms	14 ms

The single-digit-millisecond local routing figures for turn-by-turn navigation (0.69 ms on the same graph class) are measured and analysed separately in TR-2026-04.

6 · Data-layer efficiency: compression and integrity

The same mathematical framework carries the data layer. All comparison tools were run identically on the same inputs and machine; results are stated for the measured corpus, not asserted in general.

Table 7. Integrity-check throughput on the benchmark machine (higher is better). The Elara check and xxHash are non-cryptographic integrity checks (the same class); SHA-256 is a cryptographic hash with a different (adversarial) guarantee and is shown as a reference point, not a competitor.
Method	Throughput	Note
Elara integrity check (own construction, non-cryptographic)	30 GB/s	fastest non-cryptographic check measured in this trial
xxHash	21 GB/s	fastest widely deployed non-cryptographic hash
SHA-256	0.49 GB/s	cryptographic hash (different guarantee class); a reference point, not a competitor

Table 8. Lossless compression of a real 162 MB production system log.
Corpus	Result	Fidelity
Logs, records and telemetry (162 MB system log)	93% reduction (14.4× vs raw): one third smaller than gzip -9, 6% smaller than Brotli -q 11 on this corpus; never larger than either at those settings on any tested input	byte-for-byte identical, SHA-256 verified

Readers need not take the corpus on faith: any file can be submitted to the live system and the result verified, then the full field re-run locally with python bench_field.py.

7 · Statement of reproducibility

Every figure in this report derives from a fixed, published random seed and an on-disk receipt. The benchmark instances, the time budget applied to each solver, the baseline configuration, and the independent validation procedure are stated in full, so that any reader can reproduce each number or locate the exact point of disagreement. Where a result approaches an information-theoretic or complexity-theoretic bound, the bound is named and the measured distance to it is reported rather than asserted.

Every table regenerates from python bench_pack.py. The comparison tools are executed the same way, on the same machine, and the harness output is published verbatim.

8 · Limitations

The scaling study (Tables 1–2) uses seeded synthetic instances for controlled size sweeps; the formal community benchmark sets, with their own conventions and best-known solutions, are reported under a stricter protocol in TR-2026-01.
All timings are from a single consumer-grade machine and a single fixed seed; multi-seed dispersion is named future work.
Compression results are corpus-specific. The stated guarantee is bounded: never larger than gzip or Brotli on any tested input; the 93%/6% figures belong to the measured log corpus.
The OR-Tools baseline is our configuration of a free solver, disclosed in the harness; commercial solvers are not yet in this comparison.

References

Uchoa, E., Pecin, D., Pessoa, A., Poggi, M., Vidal, T., & Subramanian, A. (2017). New benchmark instances for the capacitated vehicle routing problem. European Journal of Operational Research, 257(3), 845–858.
Solomon, M. M. (1987). Algorithms for the vehicle routing and scheduling problems with time window constraints. Operations Research, 35(2), 254–265.
Perron, L., & Furnon, V. (2024). OR-Tools (v9). Google. https://developers.google.com/optimization
Luxen, D., & Vetter, C. (2011). Real-time routing with OpenStreetMap data. In Proc. ACM SIGSPATIAL GIS, 513–516.
Toth, P., & Vigo, D. (Eds.) (2014). Vehicle Routing: Problems, Methods, and Applications (2nd ed.). SIAM.
Alakuijala, J., & Szabadka, Z. (2016). Brotli Compressed Data Format. RFC 7932, IETF.
Deutsch, P. (1996). GZIP file format specification version 4.3. RFC 1952, IETF.
Collet, Y. (2016). xxHash: Extremely fast non-cryptographic hash algorithm. https://xxhash.com

Data, receipts & series

Series: TR-2026-01 (benchmark paper, community instance sets) · EL-2026-01 (evidence ledger) · TR-2026-03 (correctness under adversarial review) · TR-2026-04 (local computation in navigation) · TR-2026-05 (comparison against consumer map APIs)
Baselines: Google OR-Tools · OSRM published requirements · gzip · Brotli · xxHash · SHA-256 · Harnesses: bench_pack.py, bench_field.py
A related, independently checkable datum: the founder's efficiency record on the public GIMPS registry is analysed with machine-checked statements in the GIMPS significance analysis.
© 2026 Elara-Cortex Mathematical Infrastructure for Complex Systems · New Jersey · Johannesburg · The Elara mathematical framework is proprietary; all benchmark materials needed for verification are public; every result is measured, never simulated.