StringScanner performance proposal: Refactor to skip string allocations when not used

[jneen]

Discussion

Currently, all StringScanner scanning or checking methods delegate to the private helper #match (sometimes via #scan). All of these unconditionally perform a #byte_slice on the source string, allocating a string the length of the match.

However, many applications, especially those using #skip, completely ignore the resulting string.

Proposal

• Refactor #match to not return the string, and instead grab the source string directly in the various #scan and #check overloads, ideally using @last_match[0].
• For regex matches, this would result in grabbing the string directly from the PCRE match object rather than re-slicing it from the source string.
• Make StringMatchData lazy - instead of holding the pre-sliced string, it should hold the source string and byte offset/length, and allocate the sliced string only when required by #[].
• Benchmark the above and verify that it actually saves time/allocations.

Alternatives

We could also avoid allocation with a StringView or StringSlice type of some kind, similar to this thread. This would complicate GC somewhat, but in terms of StringScanner-based parsers it is common to keep the original source code live anyways, to slice bits out of it for error reporting.

[jneen]

A slight catch is that counting chars for #skip is also a bit non-trivial in multi-byte strings. Maybe we need an alternate matching method that just returns a boolean?

[ysbaddaden]

About string slices: https://forum.crystal-lang.org/t/more-slices-less-alloc/4332/7

It would be lovely to have various string and unicode methods to work with Bytes (maybe even Slice(UInt16) for UTF-16).

[jneen]

I think if I were writing StringScanner from scratch, it would make sense to have #scan return a Slice, since you're generally expected to know the source string it indexes into, and #to_s is not a particularly hard thing to do if you want to convert to its own String. But there's already so many scanning methods, it would be a huge breaking change to introduce something like that. Perhaps the existing private #match could be renamed, and a #match(...) method exposed that returns the match object, which at least for static strings can already be very similar to a slice.