You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A relatively common operation in code that's trying to be high-performance when dealing with utf8 strings is to contain an optimized path for when the input is all single-character runes.
Having such an API in the Go standard library would be helpful on the basis of utility alone. However, this function also lends itself to a high performance vectorized implementation -- in local tests simply unsafely casting the input to a []uintptr produces roughly linear speedups (presumably even greater speedups are available to brave souls willing to write AVX2 instructions).
As a result of the relative commonality, and the possibility for the stdlib to offer a more optimized implementation than users are likely to write on their own, I think it'd be beneficial to include this in the standard library. If there's interest, I'm happy to provide a patch.
The text was updated successfully, but these errors were encountered:
I could see this being in utf8.LeadingASCIICount or something like that, maybe under a better name, but only if it were commonly needed and straightforward to use correctly. I am not sure whether either of those is true. Do you have data about either of those, or even anecdotes about when it would be used?
In general "we know how to implement this function very quickly" is not enough for inclusion in the standard library.
A relatively common operation in code that's trying to be high-performance when dealing with utf8 strings is to contain an optimized path for when the input is all single-character runes.
Generally to accomplish that, you end up with an API that looks like
FindFirstMultiByteChar([]byte) int
, for example: https://github.com/ianlopshire/go-fixedwidth/blob/master/decode.go#L166-L175Having such an API in the Go standard library would be helpful on the basis of utility alone. However, this function also lends itself to a high performance vectorized implementation -- in local tests simply unsafely casting the input to a
[]uintptr
produces roughly linear speedups (presumably even greater speedups are available to brave souls willing to write AVX2 instructions).As a result of the relative commonality, and the possibility for the stdlib to offer a more optimized implementation than users are likely to write on their own, I think it'd be beneficial to include this in the standard library. If there's interest, I'm happy to provide a patch.
The text was updated successfully, but these errors were encountered: