4 ms·

An easily obtained apples-to-apples¹ table: $ for i in $(seq 3 16); do curl -sLo go1.$i.tgz https://golang.org/dl/go1.$i.linux-amd64.tar.gz

by rsc 5y ago

An easily obtained apples-to-apples¹ table: $ for i in $(seq 3 16); do curl -sLo go1.$i.tgz https://golang.org/dl/go1.$i.linux-amd64.tar.gz tar xzf go1.$i.tgz go/bin/gofmt size=$(ls -l go/bin/gofmt | awk '{print $5}') strip go/bin/gofmt size2=$(ls -l go/bin/gofmt | awk '{print $5}') echo go1.$i $size $size2 done go1.3 3496520 2528664 go1.4² 14398336 13139184 go1.5 3937888 2765696 go1.6 3894568 2725376 go1.7 3036195 1913704 go1.8 3481554 2326760 go1.9 3257829 2190792 go1.10 3477807 2166536 go1.11 3369391 2441288 go1.12 3513529 2506632 go1.13 3543823 2552632 go1.14 3587746 2561208 go1.15 3501176 2432248 go1.16 3448663 2443736 $ Size fluctuates from release to release, but the overall trendline is flat: Go 1.16 binaries are roughly where Go 1.3 binaries were. At the moment, it looks like Go 1.17 binaries will get a bit smaller thanks to the new register ABI making executable code smaller (and faster). ¹ Well, not completely. The gofmt code itself was changing from release to release, but not much. Most of the binary is the libraries and runtime, though, so it's still accurate for trends. ² Turns out we shipped the go 1.4 gofmt binary built with the race detector enabled! Oops.

knz42 5y ago
Strip removes the symbol tables and DWARF information. But still, the sum of all the bytes advertised in symbol tables for the non-DWARF data does not sum up to the stripped size. What's the remainder about? I am reminded of how early versions of MSWord were embedding pages of heap space in save files that were not relevant to the document being saved, just because it made the saving algorithm simpler. For all we know, the go linker could be embedding random data.
- rsc 5y ago
  > For all we know, the go linker could be embedding random data. I do know, and it is not.
  - knz42 5y ago
    > But still, the sum of all the bytes advertised in symbol tables for the non-DWARF data does not sum up to the stripped size. What's the remainder about? if you do know, then pray, what is the answer to this question?
    - rsc 5y ago
      Maybe another day I will take the time to write a full-length blog post examining the bytes in a Go binary. Today I have other work planned and still intend to do it. My points today are only that: 1. Go binary size has not gotten dramatically better or worse in any particular release and is mostly unchanged since Go 1.3. 2. Many claimed facts in the blog post are incorrect. 3. The linker is not "embedding random data" into Go binaries as you conjectured in the comment above. Stepping back a level, you don't seem to be interested in engaging in good faith at all. I'm not going to reply to any more of your comments.
      - hobbified 5y ago
        It's a mystery, not a lynch mob. Everyone reading is interested in knowing "huh, what is this stuff then?"
        ngrilly 5y ago
        Russ is totally right. Pretending the linker is embedding “random data” is just trolling.
        hobbified 5y ago
        I mean on everyone else's part.
        harikb 5y ago
        You must know that breaking down and verifying someone else's analysis is more time consuming than writing your own. Just like dealing with a bug in another person's code. Given them the benefit of doubt that Go team is cautious about binary size. People have dug in to this. Sure, they could do a better job giving some breakdown, but claiming that they are careless deserves that kind of response. Given a choice of their time, I would rather have them work on some other Go language problem. Most low hanging fruit has already been had. See [1] [2] [3] [1] https://dave.cheney.net/2020/05/09/ensmallening-go-binaries-by-prohibiting-comparisons https://dave.cheney.net/2020/05/09/ensmallening-go-binaries-... [2] https://dave.cheney.net/tag/performance https://dave.cheney.net/tag/performance [3] https://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements https://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvem...
- Footkerchief 5y ago
  > For all we know, the go linker could be embedding random data To all the people reading this as a literal accusation instead of hyperbole: plase consider that this reading is only possible under the same bad faith that you're attributing to knz42.
gampolt 5y ago
https://lobste.rs/s/gvtstv/my_go_executable_files_are_still_getting#c_dbfije https://lobste.rs/s/gvtstv/my_go_executable_files_are_still_... here is apple to apple compare for compile cockroachDB 1.0 across go 1.8 to 1.16, it's 20% smaller not bigger go 1.8 = 58,099,688 go 1.16 = 47,317,624

by rsc 5y ago

knz42 5y ago

Strip removes the symbol tables and DWARF information. But still, the sum of all the bytes advertised in symbol tables for the non-DWARF data does not sum up to the stripped size. What's the remainder about? I am reminded of how early versions of MSWord were embedding pages of heap space in save files that were not relevant to the document being saved, just because it made the saving algorithm simpler. For all we know, the go linker could be embedding random data.

rsc 5y ago
> For all we know, the go linker could be embedding random data. I do know, and it is not.
- knz42 5y ago
  > But still, the sum of all the bytes advertised in symbol tables for the non-DWARF data does not sum up to the stripped size. What's the remainder about? if you do know, then pray, what is the answer to this question?
  - rsc 5y ago
    Maybe another day I will take the time to write a full-length blog post examining the bytes in a Go binary. Today I have other work planned and still intend to do it. My points today are only that: 1. Go binary size has not gotten dramatically better or worse in any particular release and is mostly unchanged since Go 1.3. 2. Many claimed facts in the blog post are incorrect. 3. The linker is not "embedding random data" into Go binaries as you conjectured in the comment above. Stepping back a level, you don't seem to be interested in engaging in good faith at all. I'm not going to reply to any more of your comments.
    - hobbified 5y ago
      It's a mystery, not a lynch mob. Everyone reading is interested in knowing "huh, what is this stuff then?"
      - ngrilly 5y ago
        Russ is totally right. Pretending the linker is embedding “random data” is just trolling.
        hobbified 5y ago
        I mean on everyone else's part.
      - harikb 5y ago
        You must know that breaking down and verifying someone else's analysis is more time consuming than writing your own. Just like dealing with a bug in another person's code. Given them the benefit of doubt that Go team is cautious about binary size. People have dug in to this. Sure, they could do a better job giving some breakdown, but claiming that they are careless deserves that kind of response. Given a choice of their time, I would rather have them work on some other Go language problem. Most low hanging fruit has already been had. See [1] [2] [3] [1] https://dave.cheney.net/2020/05/09/ensmallening-go-binaries-by-prohibiting-comparisons https://dave.cheney.net/2020/05/09/ensmallening-go-binaries-... [2] https://dave.cheney.net/tag/performance https://dave.cheney.net/tag/performance [3] https://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements https://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvem...
Footkerchief 5y ago
> For all we know, the go linker could be embedding random data To all the people reading this as a literal accusation instead of hyperbole: plase consider that this reading is only possible under the same bad faith that you're attributing to knz42.

gampolt 5y ago

https://lobste.rs/s/gvtstv/my_go_executable_files_are_still_getting#c_dbfije https://lobste.rs/s/gvtstv/my_go_executable_files_are_still_... here is apple to apple compare for compile cockroachDB 1.0 across go 1.8 to 1.16, it's 20% smaller not bigger go 1.8 = 58,099,688 go 1.16 = 47,317,624