Optimize String code unit search with V128#3816
Open
Yu-zh wants to merge 1 commit into
Open
Conversation
Collaborator
Coverage Report for CI Build 5169Coverage decreased (-0.1%) to 91.111%Details
Uncovered Changes
Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
Yu-zh
marked this pull request as ready for review
July 16, 2026 06:56
This file contains hidden or 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
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.
Summary
String::contains_code_unitandStringView::contains_code_unitwith eight-wide scans on native and wasm targetsWhy
Code-unit searches previously inspected one UTF-16 code unit at a time. The new intrinsic allows native and wasm backends to scan eight code units per iteration while preserving the existing behavior and public API.
Impact
Long missing or late-match searches are substantially faster on SIMD-enabled targets. String views continue to honor their exact backing-string bounds, and non-native/non-wasm targets keep the scalar path. Generated package interfaces are unchanged.
Benchmark
Isolated native ARM64 release runs comparing the scalar baseline with this implementation (lower is better):
String, absent, n=4String, absent, n=8String, present at 0, n=8String, absent, n=256StringView, absent, n=256The SIMD path improves full scans substantially while keeping the immediate-match case effectively unchanged.
Validation
moon fmtmoon info(no.mbtichanges)moon check --target all -p builtinmoon test --target all -p builtinmoon test: 6,716 passed