Create a binary-size working group

[thomcc]

Proposal

The binary size of Rust programs and libraries is a frequent complaint from users, so in order to centralize and track all efforts that reduce binary size of these artifacts, we propose forming a Binary Size Working Group (wg-binary-size) under t-compiler with support from t-libs.

This working group aims to, ultimately, reduce the binary size of Rust programs, or at least give users the tools to do so. To support that top-level goal, the group will work towards:

• Identifying causes of binary bloat in Rust programs. This likely requires implementing (or extending) tooling to help measure this.
• Triaging the backlog of I-heavy issues.
• Identifying and addressing situations where our existing features for reducing binary size are insufficient or counter-productive (-Copt-level=z being larger than other opt-levels is a frequent complaint).
• Identifying worthwhile size optimizations in the stdlib, and performing them.
• Identifying and filling any gaps that exist in our documentation reducing Rust binary size.
• Extending the performance suite to better detect cases where binary size improvements and/or regressions occur as a result of compiler changes.
• Identifying cases where a new feature needs to be implemented, completed, or stabilized in the compiler, build tooling, library or even language, and try and work towards that. (Of course the ultimate decision here lies in the hands of the relevant teams).

And so on. Note that it seems very likely that the precise contents of this list will change/fluctuate as a result of measurement and data gathering.

Scope

The focus of the group is primarily artifacts which are frequently distributed or installed (for example bin, cdylib, dylib, or staticlib crates). Concretely, some things which are not considered in-scope include the total size of cargo's target directory, rustup toolchain bundles, or ephemeral build arifacts (for example metadata, incremental cache, and so on).

Explicitly in-scope are build configurations where std is present (in addition to no_std), and even optimization levels besides s and z (for example, if we can reduce the binary size of opt-level=3 without hurting performance, that would be a win).

Team

The leads will be myself (@thomcc) and Mara Bos (@m-ou-se). The initial list of members will be @davidtwco, @nbdd0121, @Kobzol, @nnethercote, @h1467792822, @workingjubilee, and @wain303009 although may grow over time.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[oli-obk]

@rustbot second

[tgross35]

Link to the wg stream: https://rust-lang.zulipchat.com/#narrow/stream/405744-wg-binary-size/topic/stream.20events