These routines could be generalized and put in their own crate.
We use functions like str::trim all over the codebase, but it's quite slow as it handles non-ASCII characters in its hot path. But typical JS code which Oxc processes is almost entirely ASCII, so we can benefit from routines optimized for ASCII, which handle non-ASCII characters in a cold path.
https://github.com/oxc-project/oxc/pull/6151 introduced string search routines optimized for ASCII strings for parsing JSX pragmas.
These routines could be generalized and put in their own crate.
We use functions like
str::trim
all over the codebase, but it's quite slow as it handles non-ASCII characters in its hot path. But typical JS code which Oxc processes is almost entirely ASCII, so we can benefit from routines optimized for ASCII, which handle non-ASCII characters in a cold path.trim_end
introduced in https://github.com/oxc-project/oxc/pull/6151 is a great deal smaller and faster on its hot ASCII path thanstd::str::trim_end
: https://godbolt.org/z/4nfW6183zWe can also provide optimized string search routines where the character being searched for is ASCII (typical usage).
We may want to replicate Rust's nightly std::ascii::Char or reuse parts of the ascii crate.