Remove unaligned vertex accesses #175
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
Maxxen
changed the title
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 PR avoid potential unaligned reads of geometry vertices that sometimes occurs after DuckDB performs a slice operation on a blob vector, by replacing raw pointer accesses with a memcpy. In practice this only affects the functions that are natively implemented in duckdb (all GEOS based operations performs a copy anyway), and on modern CPU's the performance difference should be negligible. Although it may hinder autovectorization or impact other compiler optimizations negatively.
However, this is somewhat temporary.
I have previously looked into making changes inside DuckDB to ensure that blob heap pointers remain 8 or 16-byte aligned, and while its doable, its not trivial, so we will have to do with this for a while. But I'm also working on a rework of the native geometry structures to support 3D/4D geometry ops which will change the de/serialization logic as well, so we may also revisit this then (e.g. use raw pointers unless we detect the data to be misaligned during deserialization, in which case we do a copy of the whole geometry blob)