Optimisation of `impl Compare<&[u8]> for &[u8]` is not optimal about nom HOT 5 OPEN

I tried this change on a related parser combinator library where the bench is parsing a very large json file

• Iterator: 9.5 ms
• Equality: 11.6 ms

from nom.

I tried this change on a related parser combinator library where the bench is parsing a very large json file

• Iterator: 9.5 ms

• Equality: 11.6 ms

Would you mind sharing the project and JSON file? I'd love to poke around at the binaries to see what's going on

from nom.

Would you mind sharing the project and JSON file? I'd love to poke around at the binaries to see what's going on

• https://github.com/winnow-rs/winnow
• https://github.com/winnow-rs/winnow/tree/main/third_party/nativejson-benchmark/data

I ran cargo bench --bench json -- basic/canada

from nom.

Something I suspect is what your code gets inlined into has as much affect as your actual code on performance.

A possible alternative experiment is to not inline the compare call. Those are a mix of inherited from nom or added later. In a lot of cases, they dramatically helped with performance but I've also found cases where they hurt.

from nom.

This is interesting, and it's always a good idea to revisit old optimisations to see if they still hold up. I'll look a bit into it. I suspect here that if the simpler version is slower, it is due to the overhead of calling into bcmp. Compare in nom is mainly used for very short strings, so for those a small loop might be faster

from nom.