4 ms·

its also one of the fastest these things were a choice

• rowanG077 6y ago
  A feature flag doesn't have to impact compiler performance unless enabled.
  • PudgePacket 6y ago
    I don't know if it would be in the spirit of Go. (I'm not for/against the philosophy of the decision making, just pointing it out).
  • gameswithgo 6y ago
    it does, indirectly in a few ways. code size affects performance, human effort spread over more code paths, more branches. you could have two totally separate compilers, which go does, there is the gcc variant. i don’t know if it tends to produce faster binaries though.
• lostmyoldone 6y ago
  It's even faster (at least on OSX) if you can invoke it correctly, which at least 2 years ago was almost impossible. If you manage to supply exactly the packages (transitively), and not a wildcard more, it would avoid recompiling the system libraries on each invocation. One would think a compiler where so much effort was put into making it fast would make it easy to have it run fast? The primitives were sort of there, but they didn't really fit together, and I actually had to write quite a bit of script/code to make it work. Got very fast though, thought I broke it the first time I got it to work. <return> and instant prompt. Toke me a while to convince myself it was actually compiling anything at all. Cut the recompile time in a VM to less than a tenth. Still slowed down by some pointless file IO (don't remember exactly what) but that was less of an issue. Vanity package URL's though was what broke this camels back, after GOPATH and some other miscellanea had strained it. When I ... probably needed to quickly fork+fix an external package, and suddenly had this additional obstacle, I was so ... unhappy. Already too much work, and then you get more work for exactly no discernible reason at all. It's even called a vanity url officially.