Fix remaining memory issues during the last 0.5% of processing planet.osm with the dense memory cache #108
Conversation
This file contains 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
… nodes during computation of the geometric relations
…le-length integer, store this integer in a string, and use this string as an ID for libspatialjoin. This makes use of the fact that our IDs are always pairs of <type> and <int> and has the following benefits: (1) the ID size of a typical OSM id goes down from around 18 bytes to around 5 bytes, (2) the disk space required for the geometry cache (where these IDs are stored in) is reduced, especially for nodes (where ONLY the id is stored on disk), the memory overhead of the relation tracking (via libspatialjoins "collection of geometry refs" functionality) is greatly reduced. Note: for further optimiziations regarding the memory problem with the dense RAM cache, I am waiting for profiling results from massif
|
@patrickbr @lehmann-4178656ch I didn't have time for #107 yesterday anymore and will look into it today |
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.
This is an unfinished draft PR to fix the remaining memory issues in the final 0.5% of phase 2 (dump) when processing
planet.osmwith the dense RAM cache.The current version attempts to further reduce the memory and disk space overhead of calculating the geospatial relations.
libspatialjoinrequires string IDs to identify geometries. Previously, the full prefixed IRI (e.g.osmnode:3454354544) was used as an ID. With 492069c, we use the more efficient schemawhere
[type]is a single byte identifier (1 for nodes, 2 for ways, 3 for way areas, 4 for relation area, and 5 for relations), and[integer id]is the OSM ID encoded as a variable-length integer. These bytes are directly stored in astd::stringused as the ID forspatialjoin.spatialjoinnever interprets these IDs, so they can contain arbitrary byte sequences. In particular, note thatlibspatialjoinstores them asstd::strings, not C strings, so 0 bytes are allowed and will be returned from the cache correctly (otherwise, IDs like 128 would not work).This has the following benefits:
libspatialjoins "collection of geometry refs" functionality) is greatly reduced.For a further reduction of the memory footprint in the final 0.5%, I am waiting for profiling results from massif.