4 ms·

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.
  • JoeAltmaier 11y ago
    Some languages have const methods. Exactly so the compiler can automatically optimize things like this (calling Itoa several times on the same value).
  • masklinn 11y ago
    The question is not about the result of the function it's about the function itself, aka if you have X.Y.Z.get("Q") X.Y.Z.get("R") does the runtime resolve the X.Y.Z.get chain once or twice.
    • laumars 11y ago
      I don't know and wouldn't like to guess. But that's just namespacing anyway, so I doubt it's going to carry that much overhead. In any case, that's not what the article was discussing and not what the majority of the comments on HN were discussing either.
      • laumars 11y ago
        Sorry, I'm suffering from manflu at the moment so my brain isn't running at full capacity; which means someone will have to explicitly spell out why my comment was downvoted. I'm assuming I've errored somewhere - in which case I'd welcome the opportunity to learn something :)
• stonemetal 11y ago
  What can you say Go prefers fast compilation to smart compilation.
• jerf 11y ago
  In an imperative language, proving the constancy of even slightly non-trivial values turns out to be surprisingly difficult. Again, nothing specific to Go here; you'd likely be surprised what the compiler can't assume in almost any imperative language. I was just trying to make a quick, generic point. If it helps, imagine 4 chained method calls instead. I haven't checked but if it was just a struct navigation (X.Y.Z.A.C, no method calls) Go probably does just optimize it to the correct offset. But bear in mind that will be an expensive pattern for CPython or Perl, for instance.
  • pcwalton 11y ago
    > In an imperative language, proving the constancy of even slightly non-trivial values turns out to be surprisingly difficult. No, it's not. A mature compiler backend can successfully do this in most cases (as in, most values in most programs are proved constant). SSA form coupled with SROA, SCCP, aggressive inlining, and memory analyses are really powerful. You just need a mature, optimizing backend. > Again, nothing specific to Go here; you'd likely be surprised what the compiler can't assume in almost any imperative language. Mature compilers are pretty good. They can usually figure out things you expect them to. People talk a lot about aliasing and what that means for const and the like, and that's usually where the gotchas lie, but Go, like most type-safe languages, is (presumably) much friendlier to the compiler than C is in this area.
    • jerf 11y ago
      My point is not that it's hard or impossible... the key word is surprised. I think most people would be surprised if they dug into what their compiler can't actually prove, especially in languages like Python. Which I mentioned by name as something I was explicitly including in the scope of my point. Which really should have been a clue to you. With all due respect, would you please give me a bit more principle-of-charity here? You too often pop up after a post of mine to "correct" your own too-narrow reading of it in the first place. HN is not always discussing programming things strictly in terms of Rust or similar languages; that's still just one region of a rich space. Whether or not you think Python or Perl is a disaster of a language or not, the fact remains I have, in real life, performed non-trivial speedups of real code experiencing real problems simply by trimming those lookups, and the fact that it wouldn't have been a problem in C++ or Rust or whatever isn't particularly relevant at that point. And the fact also remains that even when the compiler is not bothered, it's still bad software engineering to create such redundant code anyhow, since it's hard to see what the code is really doing under all the cruft. (I was just complaining about how Erlang code tends to create that problem rather a lot on reddit, actually.... another language where the compiler won't save you....) And thus, it is still a perfectly valid point on a diverse site like HN to point these things out.