6 ms·

...which are (basic) best practices in any programming language.

bsaul 11y ago
And since the optimization also was about not making a call to a database in every loop iteration if you don't need to, i'd say it's also pretty basic stuff. Am i missing something as to why this is on the front page ?
- SeanDav 11y ago
  Its Go. Current darling on HN. One could write a blog on how to format "hello world" in Go/Golang and it would likely make the front page, especially if it was given a catchy title like "Critical string optimizations in Go"
- coldtea 11y ago
  >Am i missing something as to why this is on the front page ? Only that fact that it's a social bookmarking site -- so whatever is voted gets to the front page. In other words: lots of HN readers find it interesting.
- maxxxxx 11y ago
  I remember reading somewhere to become a star in programming you just need to look up some papers from 10 years ago and republish them. Everybody has forgotten them since then so this stuff is suddenly innovative.
- jsight 11y ago
  It is Go and the title is interesting. I suspect that many of the upvoters didn't read the article and conclusions before voting. That usually works out ok, but sometimes it results in upvoting really obvious things like this.
laumars 11y ago
As obvious as this advice is (and to be fair, to many of us it is exceedingly obvious!) I'm constantly amazed at the amount of code I see in production services that don't use local variables for storing frequently accessed methods or functions (even from experienced developers!!) and code that fails basic load tests because developers make new database requests inside -which should be- tight loops. So I can see submissions like this still benefiting some developers.
- ant6n 11y ago
  Not a Go programmer here. .. Wait, you have to alias methods to get performance? Isn't that the compilers' job?
  - jerf 11y ago
    I'm guessing what was meant was more like code where you see X.Y.Z.get("Q") over and over and over again, even though it can't change, and the X, Y, Z, and Q are never that short. Nothing Go-specific about that anti-pattern, I'm afraid.
    - laumars 11y ago
      Indeed. And for what it's worth, the real world examples I was thinking of where developers have used this anti-pattern, the code was written in Go.
    - ant6n 11y ago
      I feel that if X, X.Y, and X.Y.Z are const within the function, the compiler should figure that out.
      - coldtea 11y ago
        And a sufficiently smart compiler/interpreter would. In practice it doesn't always. Python for example, doesn't.
        masklinn 11y ago
        Things are more complex in Python (or Ruby) as semantically each attribute access is a method call.
      - laumars 11y ago
        Excuse me for stating the obvious, but methods are not constants. They're functions inside classes. Thus they could theoretically return different results when called with the same arguments, even when called sequentially. For example, the methods could return a randomized number; or return an array with values added or removed from the stack; or uses logic based on the system clock. It would be difficult for a compiler to reliably tell whenever a method behaves like a constant without adding to the compilation time - and that simply isn't an option for JIT runtimes nor Go. And given it's a pretty basic optimisation for humans to pick up, I reckon it's also pretty low down on the list of "must have" features for compiler optimisations.
thomasahle 11y ago
The first one is only necessary in languages where functions can have side effects. Otherwise the compiler can easily deduplicate that for you. In most cases you would of course still name the result yourself, as to indicate that the function call indeed is the same. However for something very semantic, such as `sum(list)`, maybe the only name you could give it, would be something like `list_sum` anyway.
- sspiff 11y ago
  > The first one is only necessary in languages where functions can have side effects To be more precise, it is only necessary in language where all functions can have side effects. Some language (like D) have the ability to mark a function as "pure" (without side effects), which allow the compiler to perform additional optimizations (and purity validation).
- coldtea 11y ago
  >The first one is only necessary in languages where functions can have side effects. Which makes it, practically speaking, almost all of them...

bsaul 11y ago

And since the optimization also was about not making a call to a database in every loop iteration if you don't need to, i'd say it's also pretty basic stuff. Am i missing something as to why this is on the front page ?

SeanDav 11y ago
Its Go. Current darling on HN. One could write a blog on how to format "hello world" in Go/Golang and it would likely make the front page, especially if it was given a catchy title like "Critical string optimizations in Go"
coldtea 11y ago
>Am i missing something as to why this is on the front page ? Only that fact that it's a social bookmarking site -- so whatever is voted gets to the front page. In other words: lots of HN readers find it interesting.
maxxxxx 11y ago
I remember reading somewhere to become a star in programming you just need to look up some papers from 10 years ago and republish them. Everybody has forgotten them since then so this stuff is suddenly innovative.
jsight 11y ago
It is Go and the title is interesting. I suspect that many of the upvoters didn't read the article and conclusions before voting. That usually works out ok, but sometimes it results in upvoting really obvious things like this.

laumars 11y ago

As obvious as this advice is (and to be fair, to many of us it is exceedingly obvious!) I'm constantly amazed at the amount of code I see in production services that don't use local variables for storing frequently accessed methods or functions (even from experienced developers!!) and code that fails basic load tests because developers make new database requests inside -which should be- tight loops. So I can see submissions like this still benefiting some developers.

ant6n 11y ago
Not a Go programmer here. .. Wait, you have to alias methods to get performance? Isn't that the compilers' job?
- jerf 11y ago
  I'm guessing what was meant was more like code where you see X.Y.Z.get("Q") over and over and over again, even though it can't change, and the X, Y, Z, and Q are never that short. Nothing Go-specific about that anti-pattern, I'm afraid.
  - laumars 11y ago
    Indeed. And for what it's worth, the real world examples I was thinking of where developers have used this anti-pattern, the code was written in Go.
  - ant6n 11y ago
    I feel that if X, X.Y, and X.Y.Z are const within the function, the compiler should figure that out.
    - coldtea 11y ago
      And a sufficiently smart compiler/interpreter would. In practice it doesn't always. Python for example, doesn't.
      - masklinn 11y ago
        Things are more complex in Python (or Ruby) as semantically each attribute access is a method call.
    - laumars 11y ago
      Excuse me for stating the obvious, but methods are not constants. They're functions inside classes. Thus they could theoretically return different results when called with the same arguments, even when called sequentially. For example, the methods could return a randomized number; or return an array with values added or removed from the stack; or uses logic based on the system clock. It would be difficult for a compiler to reliably tell whenever a method behaves like a constant without adding to the compilation time - and that simply isn't an option for JIT runtimes nor Go. And given it's a pretty basic optimisation for humans to pick up, I reckon it's also pretty low down on the list of "must have" features for compiler optimisations.

thomasahle 11y ago

The first one is only necessary in languages where functions can have side effects. Otherwise the compiler can easily deduplicate that for you. In most cases you would of course still name the result yourself, as to indicate that the function call indeed is the same. However for something very semantic, such as `sum(list)`, maybe the only name you could give it, would be something like `list_sum` anyway.

sspiff 11y ago
> The first one is only necessary in languages where functions can have side effects To be more precise, it is only necessary in language where all functions can have side effects. Some language (like D) have the ability to mark a function as "pure" (without side effects), which allow the compiler to perform additional optimizations (and purity validation).
coldtea 11y ago
>The first one is only necessary in languages where functions can have side effects. Which makes it, practically speaking, almost all of them...