Ok I see that is a smart method indeed:

Meaning that for single bytes delimiters the boost will be very high as well (now idea how much it is common)

I suspect single-byte delimiters are fairly common, e.g. a single newline character.

Nice, so let's wait the user feedback...
What's good about SWAR wasn't the batchy behaviour but that It amortizes mispredictions reducing the branches...I am super curious 🧐

Just some before I forgot about them...
Given that the delimiter shouldn't change, maybe would be worthy to preprocess the needle as required by the algorithm and change the current two way impl to skip bound checks when possible

In the case of multi bytes delimiters, this should further increase performance for such a frequent op

Nice one @chrisvest

@chrisvest can you also port this to main if needed ?

For what it's worth, downstream we have ended up doing https://git.opendaylight.org/gerrit/c/netconf/+/101892/1/netconf/netconf-netty-util/src/main/java/org/opendaylight/netconf/nettyutil/handler/NetconfEOMAggregator.java

The point is that the base class is not @sharable and therefore has context. While the two-way is a nice optimization, I think remembering previously-checked ranges is more beneficial. Our use case entails relatively small message chunks (couple of KiB) being aggregated to large messages (10s of MiB).

EOM marker is multi-byte in this case.

@rovarga we love PRs... If you have some ideas how to improve things just open a PR :)

@rovarga in your commit you are indeed making use of ByteBuf::indexOf(byte) that has been recently improved, but you don't use the two way one for the isEom method: ByteBuf:;getByte while performed by user code is both performing bound and accessibility checks, while many of the internal search API can skip those.