3 ms·

FTA: // NOTE(rsc): This function does NOT call the runtime cmpstring // If performance is important, the compiler should be changed // to recognize the p

FTA: // NOTE(rsc): This function does NOT call the runtime cmpstring // If performance is important, the compiler should be changed // to recognize the pattern so that all code doing three-way // comparisons, not just code using strings.Compare, can benefit I would think that making the compiler more complex to make badly written code run faster, goes a bit against the spirit of go (https://go.dev/doc/ https://go.dev/doc/: “Go compiles quickly to machine code”). So, how much would that slow down the compiler? Any checks would have to do work wherever strings are compared, and that, I think, happens relatively often in you typical tool that handles json, URLs, etc.

aead 3y ago
There is a CL that tried to improve strings.Compare: https://go-review.googlesource.com/c/go/+/532195 https://go-review.googlesource.com/c/go/+/532195 As of now, the compiler has to generate the machine code for comparing strings twice by inserting two stringcmp calls. Compared to all the other SSA optimizations the compiler does already, this optimization seems cheap (however, maybe not straight forward to implement). Also, it improves a very common operation. Strings are compared all the time.
- Someone 3y ago
  > Compared to all the other SSA optimizations the compiler does already, this optimization seems cheap It probably is cheap, but if you keep piling cheap optimizations on top of each other, you can easily end up with a slow compiler. > Also, it improves a very common operation. Strings are compared all the time. Yes, strings are compared all the time, but that doesn’t imply it improves a common operation. It only improves the three-way comparison case. I think (but don’t have data) that’s a lot rarer. That strings are compared all the time also means the cheap optimization has to run ‘all the time’, most of the time only to decide that it can’t do any good. Because of that, if you have a time budget for the compiler (and I think the go people have one, at least informally), that may be better spent on other optimizations. Also, the three-way comparison has a perfectly fine workaround: call the intrinsic. That PR makes that a bit nicer by wrapping the intrinsic, and it removes the gotcha from the standard library. I think I would leave it at that. Of course, the optimization still may be beneficial, but to decide that, we would need data on how often that optimization would be beneficial in real-world code.

aead 3y ago

There is a CL that tried to improve strings.Compare: https://go-review.googlesource.com/c/go/+/532195 https://go-review.googlesource.com/c/go/+/532195 As of now, the compiler has to generate the machine code for comparing strings twice by inserting two stringcmp calls. Compared to all the other SSA optimizations the compiler does already, this optimization seems cheap (however, maybe not straight forward to implement). Also, it improves a very common operation. Strings are compared all the time.

Someone 3y ago
> Compared to all the other SSA optimizations the compiler does already, this optimization seems cheap It probably is cheap, but if you keep piling cheap optimizations on top of each other, you can easily end up with a slow compiler. > Also, it improves a very common operation. Strings are compared all the time. Yes, strings are compared all the time, but that doesn’t imply it improves a common operation. It only improves the three-way comparison case. I think (but don’t have data) that’s a lot rarer. That strings are compared all the time also means the cheap optimization has to run ‘all the time’, most of the time only to decide that it can’t do any good. Because of that, if you have a time budget for the compiler (and I think the go people have one, at least informally), that may be better spent on other optimizations. Also, the three-way comparison has a perfectly fine workaround: call the intrinsic. That PR makes that a bit nicer by wrapping the intrinsic, and it removes the gotcha from the standard library. I think I would leave it at that. Of course, the optimization still may be beneficial, but to decide that, we would need data on how often that optimization would be beneficial in real-world code.