pjfanning commented on PR #2306: URL: https://github.com/apache/pekko/pull/2306#issuecomment-3381378641
Benchmark testing with https://github.com/pjfanning/pekko-bench/tree/indexOf shows that the new code has better performance. ``` [info] Benchmark Mode Cnt Score Error Units [info] IndexOfSliceBench.indexOfSliceByteString0Compact thrpt 3 170972026.909 ± 950921237.250 ops/s [info] IndexOfSliceBench.indexOfSliceByteString0Concat thrpt 3 62923083.158 ± 80172894.188 ops/s [info] IndexOfSliceBench.indexOfSliceByteStringCompact thrpt 3 52554838.440 ± 8384708.327 ops/s [info] IndexOfSliceBench.indexOfSliceByteStringConcat thrpt 3 22211242.061 ± 38497866.157 ops/s [info] IndexOfSliceBench.indexOfSliceBytes0Compact thrpt 3 142160935.848 ± 842800972.850 ops/s [info] IndexOfSliceBench.indexOfSliceBytes0Concat thrpt 3 68818647.909 ± 43520695.803 ops/s [info] IndexOfSliceBench.indexOfSliceBytes1Compact thrpt 3 106181468.854 ± 72102056.049 ops/s [info] IndexOfSliceBench.indexOfSliceBytes1Concat thrpt 3 31358546.706 ± 63361128.277 ops/s ``` * indexOfSliceByteStringCompact is the legacy * indexOfSliceByteString0Compact is a new override * indexOfSliceBytes0Compact searches for `Array[Byte]` instead of `Seq[B :> Byte]` * indexOfSliceBytes1Compact uses a different algorithm that is theoretically better for concatenated ByteStrings but in practice is worse than the 0 algorithm at least in the use cases tested This PR drops use of the second algorithm. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
