Use byte-based storage for edges #2993
Merged
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
easbar
reviewed
Apr 29, 2024
core/src/test/java/com/graphhopper/routing/util/parsers/FootTagParserTest.java
Outdated
Show resolved
Hide resolved
karussell
commented
Apr 30, 2024
| return BitUtil.LITTLE.toULong5(bytes, 0); | ||
| int int0 = edges.getInt(edgePointer + E_GEO); | ||
| byte byte5 = edges.getByte(edgePointer + E_GEO + 4); | ||
| return BitUtil.LITTLE.toLong(int0, byte5); |
There was a problem hiding this comment.
I think byte5 & 0xFF is required because otherwise the long could get negative if the highest bit of byte5 is set. And there seems to be no speed is lost for the byte-array approach: so let's keep fromULong5 and toULong5.
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.
Replaces #2986 but with less changes.
Currently we store all properties like the distance or nodeA/B ID to the
edgesDataAccess as integer, which is a bit limiting as every property has to fit in one integer and if not, it will require two integers (instead of expanding to e.g. 5 bytes).With this change the
edgesis byte-based and we can use only 5 bytes for the georef (see #2978) and the edge flags are stored with byte-precision too i.e. this change can reduce the storage requirement by up to 6 bytes (e.g. up to 3 bytes for the edge flags plus 3 bytes less for georef).There is only a minor slowdown of 2-5% for routing and CH/LM preparation. As there was a minor speed-up found in this process the overall slowdown regarding the latest stable for the routing is neglectable.
Later this change will help if other edge properties like the edge IDs or link ID grow beyond 4 bytes.