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

std: A few code size optimizations #12616

Merged
merged 4 commits into from Feb 28, 2014
Merged

std: A few code size optimizations #12616

merged 4 commits into from Feb 28, 2014

Conversation

alexcrichton
Copy link
Member

I've been playing around with code size when linking to libstd recently, and these were some findings I found that really helped code size. I started out by eliminating all I/O implementations from libnative and instead just return an unimplemented error.

In doing so, a fn main() {} executable was ~378K before this patch, and about 170K after the patch. These size wins are all pretty minor, but they all seemed pretty reasonable to me. With native I/O not stubbed out, this takes the size of an LTO executable from 675K to 400K.

// LLVM doesn't tend to inline this, presumably because begin_unwind_fmt
// is #[cold] and #[inline(never)] and because this is flagged as cold
// as returning !. We really do want this to be inlined, however,
// because it's just a tiny wrapper. Small wins (~7K) were seen when
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

7K out of? (These numbers are more useful if they have percentages with them too)

@huonw
Copy link
Member

huonw commented Feb 28, 2014

Nice wins!

r=me addressing my comments, seems the travis failures might be related?

This is a ubiquitous type in concurrent code, and the assertions are causing
significant code bloat for simple operations such as reading the pointer
(injecting a failure point, etc).

I am testing executable sizes with no I/O implementations (everything stubbed
out to return nothing), and this took the size of a libnative executable from
328K to 207K (37% reduction in size), so I think that this is one assertion
that's well worth configuring off for now.
Most of these are unnecessary because we're only looking at static strings. This
also moves to Vec in a few places instead of ~[T].

This didn't end up getting much of a code size win (update_log_settings is the
third largest function in the executables I'm looking at), but this seems like a
generally nice improvement regardless.
This removes all usage of Poly in format strings from libstd. This doesn't
prevent more future strings from coming in, but it at least removes the ones for
now.
This function is a tiny wrapper that LLVM doesn't want to inline, and it ends up
causing more bloat than necessary. The bloat is pretty small, but it's a win of
at least 7k for small executables, and I imagine that the number goes up as
there are more calls to fail!().
bors added a commit that referenced this pull request Feb 28, 2014
I've been playing around with code size when linking to libstd recently, and these were some findings I found that really helped code size. I started out by eliminating all I/O implementations from libnative and instead just return an unimplemented error.

In doing so, a `fn main() {}` executable was ~378K before this patch, and about 170K after the patch. These size wins are all pretty minor, but they all seemed pretty reasonable to me. With native I/O not stubbed out, this takes the size of an LTO executable from 675K to 400K.
@bors bors closed this Feb 28, 2014
@bors bors merged commit ddc1c21 into rust-lang:master Feb 28, 2014
@huonw huonw mentioned this pull request Mar 1, 2014
@alexcrichton alexcrichton deleted the size branch March 1, 2014 08:38
@bstrie
Copy link
Contributor

bstrie commented Mar 3, 2014

Minor or not, getting fn main() {} down below 200 kb is definitely a milestone in my eyes. Kudos!

bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 25, 2022
Correct target_feature completion

I changed the `target_feature` to match the description given in rust-lang#12616.
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 4, 2024
avoid an ICE in `ptr_as_ptr` when getting the def_id of a local

Fixes rust-lang#12616

`Res::def_id` can panic, so avoid calling it in favor of `opt_def_id`, so we can gracefully handle resolutions that don't have a `DefId` (e.g. local variables) and get a false negative in the worst case, rather than an ICE

changelog: Fix ICE in [`ptr_as_ptr`] when the cast expression is a function call to a local variable
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 25, 2024
avoid an ICE in `ptr_as_ptr` when getting the def_id of a local

Fixes rust-lang#12616

`Res::def_id` can panic, so avoid calling it in favor of `opt_def_id`, so we can gracefully handle resolutions that don't have a `DefId` (e.g. local variables) and get a false negative in the worst case, rather than an ICE

changelog: Fix ICE in [`ptr_as_ptr`] when the cast expression is a function call to a local variable
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 25, 2024
avoid an ICE in `ptr_as_ptr` when getting the def_id of a local

Fixes rust-lang#12616

`Res::def_id` can panic, so avoid calling it in favor of `opt_def_id`, so we can gracefully handle resolutions that don't have a `DefId` (e.g. local variables) and get a false negative in the worst case, rather than an ICE

changelog: Fix ICE in [`ptr_as_ptr`] when the cast expression is a function call to a local variable
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants