GH-40280: [C++] Specialize ResolvedChunk::Value on value-specific types instead of entire class #40281
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
felipecrv
changed the title
felipecrv
changed the title
pitrou
approved these changes
Feb 29, 2024
| // The target array in chunked array. | ||
| const Array* array; | ||
| // The index in the target array. | ||
| const int64_t index; | ||
|
|
||
| ResolvedChunk(const Array* array, int64_t index) : array(array), index(index) {} | ||
|
|
||
| public: |
There was a problem hiding this comment.
I may misread, but I think we're already in a public section given that this is a struct?
There was a problem hiding this comment.
I mean to make it a class and the members private. I should have done it in this PR, but forgotten.
There was a problem hiding this comment.
I'm removing it in another PR now.
github-actions
bot
added
awaiting committer review
|
After merging your PR, Conbench analyzed the 7 benchmarking runs that have been run so far on merge-commit 214378b. There was 1 benchmark result indicating a performance regression:
The full Conbench report has more details. It also includes information about 4 possible false positives for unstable benchmarks that are known to sometimes produce them. |
thisisnic
pushed a commit
to thisisnic/arrow
that referenced
this pull request
Mar 8, 2024
…ic types instead of entire class (apache#40281) ### Rationale for this change Less template-specialization without any loss in efficiency. ### What changes are included in this PR? - `ChunkedResolver` tweak - Explicitly declare copy constructors of `ChunkedResolver` - at the moment they are necessary because `ChunkedArrayResolver` is copied in compute kernel code - Make `ChunkedArrayResolver` re-use `ChunkResolver` via composition instead of inheritance - This will allow the `ChunkResolver` API to evolve in ways that might not make sense if it's a sub-class of `ChunkedArrayResolver` - Use `std::enable_if` instead of duplicating the `ResolvedChunk` implementation and template-specializing - Only specialize `ResolvedChunk::Value` on value-type-specific types preserving the same type-safety checks (static and runtime) ### Are these changes tested? Yes, by existing tests. ### Are there any user-facing changes? No, because these are API are under the internal namespace at the moment even though there are plans to make it public. These changes are preparation for that if we end up making them public. * GitHub Issue: apache#40280 Authored-by: Felipe Oliveira Carvalho <felipekde@gmail.com> Signed-off-by: Felipe Oliveira Carvalho <felipekde@gmail.com>
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.
Rationale for this change
Less template-specialization without any loss in efficiency.
What changes are included in this PR?
ChunkedResolvertweakChunkedResolverChunkedArrayResolveris copied in compute kernel codeChunkedArrayResolverre-useChunkResolvervia composition instead of inheritanceChunkResolverAPI to evolve in ways that might not make sense if it's a sub-class ofChunkedArrayResolverstd::enable_ifinstead of duplicating theResolvedChunkimplementation and template-specializingResolvedChunk::Valueon value-type-specific types preserving the same type-safety checks (static and runtime)Are these changes tested?
Yes, by existing tests.
Are there any user-facing changes?
No, because these are API are under the internal namespace at the moment even though there are plans to make it public. These changes are preparation for that if we end up making them public.