Optimize every()
and related functions
#1169
Open
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.
Fixes #1036
This PR reimplements
every()
,some()
, andnone()
in C. I followed the C implementation ofmap()
(since I have no experience writing in C). The interface does not change at all, the behaviour should also remain intact.The key change is I did not use
as_predicate()
, butas_mapper()
instead. Now, the difference between these two functions is that the former performs a Bool check on its output. This was computationally expensive and even replacing this check with.Call()
didn't help, since the code was switching between C and R contexts a lot. My final solution was to perform these checks in C, in the same code that performs the predicate-checking loop.I had to replace the implementation of
none()
with a separate C solution, sincenegate()
had a huge overhead. However, all three functions share almost all of their C implementations now.Finally, the performance. They should be equal now (except that
every()
and friends still have their early return).Created on 2025-02-06 with reprex v2.1.1