3 ms·

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 no

• 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.