Re: [go-nuts] Weird benchmark results for seemingly identical functions

2020-06-23 Thread Yonatan Ben-Nes
So I'm probably missing something obvious again but the fact that the loops were checking different/inverse conditions should not have cause the append line to cost 300k ns/op. I'm referring to the line `lcp = append(lcp, 0)` which appear at the start of both of the functions, when I'm running

Re: [go-nuts] Weird benchmark results for seemingly identical functions

2020-06-22 Thread Nimrod Yonatan Ben-Nes
Oh the shame Thank you for pointing that out :) On Mon, 22 Jun 2020, 20:03 Martin Schnabel, wrote: > Let me quickly point out that your logic is inverted in the second code > snippet because you break on the condition. That is most likely the > reason for the difference. I guess the second

Re: [go-nuts] Weird benchmark results for seemingly identical functions

2020-06-22 Thread Martin Schnabel
Let me quickly point out that your logic is inverted in the second code snippet because you break on the condition. That is most likely the reason for the difference. I guess the second example exits on the first iteration. for pos := 0; true; pos++ { if pos < suffixLen && pos < previousSuf

Re: [go-nuts] Weird benchmark results for seemingly identical functions

2020-06-22 Thread Bakul Shah
They are not equivalent. You want if !(pos < suffixLen && pos < previousSuffixLen) {  break } in the second case.On Jun 22, 2020, at 5:15 AM, Yonatan Ben-Nes wrote:Hi,I'm encountering a weird issue which I fail to explain. It boils down to 2 almost identical functions which gi

[go-nuts] Weird benchmark results for seemingly identical functions

2020-06-22 Thread Yonatan Ben-Nes
Hi, I'm encountering a weird issue which I fail to explain. It boils down to 2 almost identical functions which give wildly different benchmark results. The difference between the functions is that at the slow func there is a for loop like this: for pos := 0; pos < suffixLen && pos < previousSu