It is not entirely clear what you are trying to accomplish. I suspect effective optimization would require rethinking or refining your algorithm.
In the benchmarks you are comparing apples to oranges. BenchmarkByteIndexPointeur searches for a 10 byte pattern in a 56 byte slice. On amd64 at least, it falls through to assembly. I have not looked at the assembly, but given that there are no substantial occurrences of the pattern prefix in search slice, I would expect it to involve around 56 comparisons in the naive case. In your code, on the other hand, the hot comparison (line 87 in the original, and line 76 in the benchmark) gets called 375 times. As I said, I'm not sure what the expected behavior is, but I suspect your algorithm is sub-optimal. Good Luck. On Wednesday, November 15, 2017 at 1:01:03 PM UTC-5, Christian LeMoussel wrote: > > I created benchmarks : https://play.golang.org/p/kgBsciRbpe > > BenchmarkByteIndex-2 5000000 210 > ns/op 64 B/op 1 allocs/op > BenchmarkByteIndexPointeur-2 20000000 90.1 > ns/op 0 B/op 0 allocs/op > BenchmarkFindByte-2 10000000 181 > ns/op 0 B/op 0 allocs/op > BenchmarkFindHex-2 1000000 1003 > ns/op 0 B/op 0 allocs/op > > the idea being that BenchmarkFindHex should be as good as > BenchmarkByteIndexPointeur, > because int32 comparison instead of byte > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
