Optimize query unpacking #27
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
Could we get separate benchmarks for the variable amounts of paths to confirm this? |
|
After more thorough benchmarking it turns out that even beyond 8 manual indices it still outperforms unpack. However at 5+ the gain is less than 15% and stays around that making the optimization not that useful. I should say checking for multiple cases has downsides as well at about 2% for queries when not enabling hot paths. we should therefore figure out the median query length and if it is above 4-5 then we should probably support that. |
|
Can we link this to an issue rather than labeling the PR directly? Issues are better for visibility when others come looking. |
jackTabsCode
approved these changes
Jan 28, 2024
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 resolves #30 where it improves performance of queries by up to 35% by optimizing query unpacking. What we do is we inline the destructering of the column data with manual indexes up to query length 4 as that is when
unpackstarts to get even in speed. This saves a lot of computation in the grand scheme of things as the optimization takes place at expand function which is invoked at every iteration.