Repository navigation
perf(ingest): store node locations in a sorted Vec - #2746
Open
timohueser wants to merge 1 commit into
Open
timohueser wants to merge 1 commit into
timohueser wants to merge 1 commit into
Conversation
The OSM ingest of obc-draw and the place harvest of obc-places kept every node of a source in a HashMap<i64, (i32, i32)>. A sorted Vec with binary search takes 16 bytes per node, and a sorted PBF fills it without a sort. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The OSM ingest kept every node of a source in a
HashMap<i64, (i32, i32)>. On a large leaf, this map is most of the ingest peak, and it doubles while it grows.This change adds
NodeCoordstoobc_places::osm. It is aVec<(i64, (i32, i32))>sorted by id, with binary search for lookups (16 bytes per node). A sorted PBF fills it in id order, sofreezedoes not sort. On a duplicate id, the first location wins. This is also the rule for a merge of sources.obc_draw::ingestandobc_places::osm::harvestboth use it, because they shareresolve_coords.Measurements
Leaf europe/dach 0037-0033 (2.5 GB PBF).
obc_draw::ingest::ingest_osm_wayswithCELL_SCHEMA. glibcmallinfo2heap in use (uordblks + hblkhd), sampled every 250 ms. Both binaries were built from clean private target dirs, base = dfdc377.2262f4fb…2262f4fb…(same)The remaining pass-2 peak is the features (30.2 M) and routable ways (8.0 M) that the ingest returns, plus the 3.8 GiB node store.
Output bytes
I replayed the whole
device/coarse/0037-0033cells step with this branch, from the stored receiptlayers/87bc80d9b47c….jsonand its PBF and land-polygons objects. 31/31 files match the stored SHA-256, with no extra files. On this base, the whole-step peak is still the LOD 8 polygonize (26.4 GiB), which #2731 removes. With #2731, ingest now stays under the step's next-largest peak.Checks
obc test -p obc-places(47 passed, including the newnode_coords_first_location_wins)obc test -p obc-draw(102 passed)cargo clippy -p obc-places --all-targets -- -D warnings,cargo clippy -p obc-draw --all-targets -- -D warningscargo fmt --all -- --checkharvestcallers (obc-pack, obc-network, obc-search-bake) and their suites.harvestgets the same lookup semantics.Public docs did not change.
Requirements: none
🤖 Generated with Claude Code