I’ve just published tz_world version 2.1.0.
The primary changes are:
-
The addition of a new backend, TzWorld.Backend.SpatialIndex that implements a pure-Elixir R-tree (Sort-Tile-Recursive packed) index. This index results in substantially faster lookups.
-
File and :json streaming to optimise the memory usage when running mix tz_world.update. This task used to consume a peak of 980Mb. It now consumes a peak of 70Mb.
The reason for the major release bump are:
Performance comparisons
Benchmarked against the previous backends across a categorised fixture set (dense regions, sparse/large zones, small/thin zones, ocean points with no match, points adjacent to the international date line):
| Input category |
Speedup vs. the next-fastest existing backend |
ocean (no-match) |
18.2× |
sparse_or_large |
1.64× |
dense (cities) |
1.43× |
| random uniform |
1.42× |
small_or_thin |
1.08× |
The largest wins are on no-match queries: previously, points in the open ocean caused a full scan of every shape’s bounding box; the R-tree exits at the root.
Memory comparison of mix tz_world.update
Version 2.0 rewrote the data-update pipeline to stream end-to-end. The source zip is downloaded straight to a temp file (no in-memory body), unzipped to disk (no in-memory JSON), parsed in 64 KiB chunks via OTP’s built-in :json module with a feature-diverting decoder callback, and each Geo.Polygon / Geo.MultiPolygon is written to the on-disk index as it is decoded. The full GeoJSON is never resident in memory at any point.
Measured BEAM peak memory of mix tz_world.update on the without-oceans dataset (158 MB GeoJSON, 419 shapes, post-GC sampled):
| Version |
Peak BEAM memory during update |
| 1.x |
≈ 920 MB |
| 2.x |
≈ 70 MB |
