Fix: update table predicate filter #24803
Closed
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.
Change the table's predicate filter to iterate through the map's array of values and check for filter inclusion. This will involve fewer passes: the current function iterates over the keys, searches the map for each key to construct a string, then searches the string. It will also remove the risk presented by the unicode delimiter.
It will also present an improvement over @daniel-brenot's PR which, similarly to the original function, iterates over the keys and then searches the map for their corresponding value. This check is superfluous when an array of values is available.
Performance-wise, a further gain in speed is present over both previous techniques. I have updated Daniel's benchmark script to include the new function, as well as some logic to print results for veracity, check failure performance, and populate a map with n generated UUIDs to help examine performance at scale.
https://jsbench.me/9bl258ffo3/2
At 1,000 entries, the original function is ~80% slower, Daniel's is ~42% slower at successes.
Failures are roughly 65%, 39% slower, respectively.
At 10,000 entries, successes are roughly 84%, 32% slower.
Failures at 10k are roughly 75%, 24% slower.
For completeness, at 10 entries, successes: 63, 11, failures: 55, 9.