bytes: trivial to beat ContainsAny in easy cases #31321
Labels
help wanted
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Performance
Milestone
See this CL: https://go-review.googlesource.com/c/go/+/155965
In short, code like
bytes.ContainsAny(data, " \t")
is easy to read and write, but a simple manual implementation as follows is considerably faster:ContainsAny
usesIndexAny
, which already has three paths; it does nothing for emptychars
, it builds an ASCII set ifchars
is all ASCII and over eight bytes, and otherwise it does a naive double-loop search.I'm not sure what the right solution here would be. I think adding more special cases to
IndexAny
would probably be overkill, and even slow down the other cases because of the added code. Making the compiler treatContainsAny
orIndexAny
in a special way is also undesirable.I guess if the compiler was super smart in the future, inlined all the code and realised that our chars are just
" \t"
, it would simply inline that last naive search code. But I imagine the current compiler is far away from that possibility.This is an unfortunate outcome, because the
bytes
andstrings
packages are very intuitive and often the fastest. I'd like to continue relying on them, without having to write my own loops by hand when they start showing up on CPU profiles./cc @josharian @randall77 @martisch
The text was updated successfully, but these errors were encountered: