5 ms·

The optimal version does seem to exist here (per the comment too): https://github.com/golang/go/blob/d28bf6c9a2ea9b992796738d03eb3d15ffbfc0b4/src/internal/byte

The optimal version does seem to exist here (per the comment too): https://github.com/golang/go/blob/d28bf6c9a2ea9b992796738d03eb3d15ffbfc0b4/src/internal/bytealg/compare_generic.go#L39 https://github.com/golang/go/blob/d28bf6c9a2ea9b992796738d03... So the goal was to intentionally nerf Compare() to discourage code the golang authors considered less clear. I'm not sure bad performance is really discouraging usage though, it just penalizes folks that use stdlib. I wonder if they'd accept a PR to switch to runtime.cmpstring today?

smt88 4y ago
> "intentionally nerf Compare() to discourage code the golang authors considered less clear" If that's true, it further proves that I disagree with the philosophy of the Go designers on pretty much everything. If your language provides multiple ways to do something, they should all be optimized in good faith. To do what you suggested is insane and user-hostile.
- somekyle2 4y ago
  Well, the question is what you want to optimize for. It's a library function that exists for consistency's sake; it's clear and simple, and reasonably fast (and near optimal in some cases). For optimal performance but suboptimal clarity, they could use a runtime implementation, but ideally the clear code would be fast, so best not to compromise the clarity for performance unless it proves important. I've been following Go content for years, this is the first I can recall hearing of it, so I'm mostly fascinated that people care, given that this seems to be doing what the most classic optimization advice suggests and not messing it up prematurely.
  - codeflo 4y ago
    “Avoid premature optimization” means to do the cleanest/clearest thing now, and only optimize later when you have the full picture. Arguably, that advice doesn’t apply to standard library functions anyway, at least not to the same extent. But if it did: How is adding a new, “bad” implementation any clearer than simply calling the already existing optimized one that the GP linked to?
    - philosopher1234 4y ago
      You should optimize when it’s net useful, not just because you know how. Making a random function faster and harder to maintain is bad engineering if the speed isn’t useful.
      - adwn 4y ago
        > Making a random function faster and harder to maintain is bad engineering if the speed isn’t useful. 1) It's not some random function, it's part of the standard library. 2) Three-way string compares are far from uncommon, and string comparisons are relatively expensive. Therefore, a speedup would be useful. Optimizing this function would not count as "premature".
      - codeflo 4y ago
        Again: How is adding a new, “bad” implementation any easier to maintain than simply calling the already existing optimized one that the GP linked to?
  - zarzavat 4y ago
    There’s no such thing as premature optimization in a language standard library. Every function should be optimized to the bitter end because everybody uses the standard library.
  - insanitybit 4y ago
    The most classic optimization advice is based on a complete misquote. Here is some critical context: > t. The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-and-pound-foolish programmers > in established engineering disciplines a 12 % improvement, easily obtained, is never considered marginal > when it's a question of preparing quality programs, I don't want to restrict myself to tools that deny me such efficiencies. > We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. Keep in mind that in this case the argument is being made against goto, which is effectively an inlined `jmp` instruction that can do all sorts of insane things just to save a few instructions. This quote is discouraging a case where the complexity is extreme and the benefit is minor. All that people can seem to remember is "premature optimization is the root of all evil". [PDF] https://dl.acm.org/doi/pdf/10.1145/356635.356640 https://dl.acm.org/doi/pdf/10.1145/356635.356640
- kubanczyk 4y ago
  > If your language provides multiple ways to do something Yeah, no. The founding principle of Go is to avoid multiple ways. If multiple ways emerge anyway, move things&people around until one of them becomes strongly preferred. There's nothing inherently bad about the approach, it's a choice which has costs and benefits.
- rjh29 4y ago
  A sane language would deprecate the function so the compiler warns (or dies) when encountering it. Go's compiler is happy to die because I have an unused import, but not this?
kitd 4y ago
Completely OT but, after 5 years of writing Go, TIL you can assign multiple LHS from multiple RHS: c1, c2 := a[i], b[i]
- rob74 4y ago
  Well, duh... I mean, that's the same mechanism that allows a function to return multiple values, and Go prides itself on its orthogonal features, so of course you can do that. Also handy for swapping: "x, y = y, x". Go isn't always more verbose than other languages...
Beltalowda 4y ago
It actually used to call this, but was changed in 2015: https://github.com/golang/go/commit/fd4dc91a96518fdbb47781f97ba43ae36df215a5 https://github.com/golang/go/commit/fd4dc91a96518fdbb47781f9... I'm not entire sure if I see the problem or follow why just using runtime·cmpstring is such a bad thing; doesn't seem that "overengineered" to me.
- esprehn 4y ago
  Yeah, that's a pretty small amount of clean up. Someone should try to revert the patch and reland it.
- icholy 4y ago
  It's because people started putting "always use strings.Compare" in their style guides.
  - tapirl 4y ago
    Even if strings.Compare is optimized, it is not always better than general comparison operators. Both strings.Compare and comparison operators have their respective best use scenarios.
- twic 4y ago
  > The function is here ONLY for symmetry with package bytes. > This function should be used ONLY if it makes code clearer. > It is not here for performance. Remove any performance benefit. Insane troll logic, pure and simple.

smt88 4y ago

> "intentionally nerf Compare() to discourage code the golang authors considered less clear" If that's true, it further proves that I disagree with the philosophy of the Go designers on pretty much everything. If your language provides multiple ways to do something, they should all be optimized in good faith. To do what you suggested is insane and user-hostile.

somekyle2 4y ago
Well, the question is what you want to optimize for. It's a library function that exists for consistency's sake; it's clear and simple, and reasonably fast (and near optimal in some cases). For optimal performance but suboptimal clarity, they could use a runtime implementation, but ideally the clear code would be fast, so best not to compromise the clarity for performance unless it proves important. I've been following Go content for years, this is the first I can recall hearing of it, so I'm mostly fascinated that people care, given that this seems to be doing what the most classic optimization advice suggests and not messing it up prematurely.
- codeflo 4y ago
  “Avoid premature optimization” means to do the cleanest/clearest thing now, and only optimize later when you have the full picture. Arguably, that advice doesn’t apply to standard library functions anyway, at least not to the same extent. But if it did: How is adding a new, “bad” implementation any clearer than simply calling the already existing optimized one that the GP linked to?
  - philosopher1234 4y ago
    You should optimize when it’s net useful, not just because you know how. Making a random function faster and harder to maintain is bad engineering if the speed isn’t useful.
    - adwn 4y ago
      > Making a random function faster and harder to maintain is bad engineering if the speed isn’t useful. 1) It's not some random function, it's part of the standard library. 2) Three-way string compares are far from uncommon, and string comparisons are relatively expensive. Therefore, a speedup would be useful. Optimizing this function would not count as "premature".
    - codeflo 4y ago
      Again: How is adding a new, “bad” implementation any easier to maintain than simply calling the already existing optimized one that the GP linked to?
- zarzavat 4y ago
  There’s no such thing as premature optimization in a language standard library. Every function should be optimized to the bitter end because everybody uses the standard library.
- insanitybit 4y ago
  The most classic optimization advice is based on a complete misquote. Here is some critical context: > t. The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-and-pound-foolish programmers > in established engineering disciplines a 12 % improvement, easily obtained, is never considered marginal > when it's a question of preparing quality programs, I don't want to restrict myself to tools that deny me such efficiencies. > We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. Keep in mind that in this case the argument is being made against goto, which is effectively an inlined `jmp` instruction that can do all sorts of insane things just to save a few instructions. This quote is discouraging a case where the complexity is extreme and the benefit is minor. All that people can seem to remember is "premature optimization is the root of all evil". [PDF] https://dl.acm.org/doi/pdf/10.1145/356635.356640 https://dl.acm.org/doi/pdf/10.1145/356635.356640
kubanczyk 4y ago
> If your language provides multiple ways to do something Yeah, no. The founding principle of Go is to avoid multiple ways. If multiple ways emerge anyway, move things&people around until one of them becomes strongly preferred. There's nothing inherently bad about the approach, it's a choice which has costs and benefits.
rjh29 4y ago
A sane language would deprecate the function so the compiler warns (or dies) when encountering it. Go's compiler is happy to die because I have an unused import, but not this?

kitd 4y ago

Completely OT but, after 5 years of writing Go, TIL you can assign multiple LHS from multiple RHS: c1, c2 := a[i], b[i]

rob74 4y ago
Well, duh... I mean, that's the same mechanism that allows a function to return multiple values, and Go prides itself on its orthogonal features, so of course you can do that. Also handy for swapping: "x, y = y, x". Go isn't always more verbose than other languages...

Beltalowda 4y ago

It actually used to call this, but was changed in 2015: https://github.com/golang/go/commit/fd4dc91a96518fdbb47781f97ba43ae36df215a5 https://github.com/golang/go/commit/fd4dc91a96518fdbb47781f9... I'm not entire sure if I see the problem or follow why just using runtime·cmpstring is such a bad thing; doesn't seem that "overengineered" to me.

esprehn 4y ago
Yeah, that's a pretty small amount of clean up. Someone should try to revert the patch and reland it.
icholy 4y ago
It's because people started putting "always use strings.Compare" in their style guides.
- tapirl 4y ago
  Even if strings.Compare is optimized, it is not always better than general comparison operators. Both strings.Compare and comparison operators have their respective best use scenarios.
twic 4y ago
> The function is here ONLY for symmetry with package bytes. > This function should be used ONLY if it makes code clearer. > It is not here for performance. Remove any performance benefit. Insane troll logic, pure and simple.