Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: reclaim binary size increase from CL 35554 constant to interface allocation optimizations #40039

thepudds opened this issue Jul 4, 2020 · 2 comments
NeedsInvestigation Performance


Copy link

@thepudds thepudds commented Jul 4, 2020

In CL 35554 for #18704, @josharian added some very nice allocation optimizations, as part of his efforts to claw back some of the allocation penalty of #8405, but a result was a modest increase in binary size.

In CL 35554, @josharian mentioned that the ~0.5% binary size increase could likely be recovered in the future, and there was some discussion of adding a tracking issue for that.

I did a quick look for that follow-up tracking issue a couple years ago, and again searched just now, but both times haven't found it.

Posting this new issue now in case it is helpful to either:

  1. serve as the tracking issue for that possible future work, or
  2. if that is already tracked (or even completed!), help a future gopher more easily follow the issue trail through cross linking ;-)

Here is a snippet from CL 35554:

This CL adds ~0.5% to binary size, despite
decreasing the size of many functions,
because it also adds many static symbols.

This binary size regression could be recovered in
future (but currently unplanned) work.

There is a lot of content-duplication in these
symbols; this statement generates six new symbols,
three containing an int 1 and three containing
a pointer to the string "a":

fmt.Println(1, 1, 1, "a", "a", "a")

These symbols could be made content-addressable.

Furthermore, these symbols are small, so the
alignment and naming overhead is large.
As with the go.strings section, these symbols
could be hidden and have their alignment reduced.

Another reason for posting now is that there is some recent renewed energy around binary size (#6853).

Sorry if I missed something obvious. @josharian or anyone else, feel free to close if this is already addressed or tracked elsewhere.

Copy link

@josharian josharian commented Jul 4, 2020

I attempted content addressability and failed, and never picked it up again.

I’m not sure whether the alignment and symbol visibility changes happened. I imagine so, but cc @cherrymui just in case.

Copy link

@thepudds thepudds commented Jul 4, 2020

Thanks @josharian for the quick comment. Also, I should have said this explicitly that of course this might not be worth doing, especially given finite time and opportunities for other improvements. 😅

@dmitshur dmitshur added the NeedsInvestigation label Jul 7, 2020
@dmitshur dmitshur added this to the Backlog milestone Jul 7, 2020
@dmitshur dmitshur removed this from the Backlog milestone Jul 7, 2020
@dmitshur dmitshur added this to the Unplanned milestone Jul 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
NeedsInvestigation Performance
None yet

No branches or pull requests

3 participants