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: Cut down #[inline] annotations where not necessary #43367

Merged
merged 1 commit into from
Jul 22, 2017

Conversation

alexcrichton
Copy link
Member

This PR cuts down on a large number of #[inline(always)] and #[inline]
annotations in libcore for various core functions. The #[inline(always)]
annotation is almost never needed and is detrimental to debug build times as it
forces LLVM to perform inlining when it otherwise wouldn't need to in debug
builds. Additionally #[inline] is an unnecessary annoation on almost all
generic functions because the function will already be monomorphized into other
codegen units and otherwise rarely needs the extra "help" from us to tell LLVM
to inline something.

Overall this PR cut the compile time of a microbenchmark by 30% from 1s to
0.7s.

@rust-highfive
Copy link
Collaborator

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton alexcrichton added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 20, 2017
@TimNN
Copy link
Contributor

TimNN commented Jul 20, 2017

Additionally #[inline] is an unnecessary annoation on almost all
generic functions because the function will already be monomorphized into other
codegen units

I'm not exactly sure, but is this still true? If I recall correctly, there were some changes (to the collector?) a while ago, which changed the behaviour here

@oyvindln
Copy link
Contributor

I know that at least that a adding inline to try_from helped that get inlined.

This PR cuts down on a large number of `#[inline(always)]` and `#[inline]`
annotations in libcore for various core functions. The `#[inline(always)]`
annotation is almost never needed and is detrimental to debug build times as it
forces LLVM to perform inlining when it otherwise wouldn't need to in debug
builds. Additionally `#[inline]` is an unnecessary annoation on almost all
generic functions because the function will already be monomorphized into other
codegen units and otherwise rarely needs the extra "help" from us to tell LLVM
to inline something.

Overall this PR cut the compile time of a [microbenchmark][1] by 30% from 1s to
0.7s.

[1]: https://gist.github.com/alexcrichton/a7d70319a45aa60cf36a6a7bf540dd3a
@alexcrichton
Copy link
Member Author

@TimNN ah yes I always forget that #[inline] affects monomorphization in codegen units as well. I've updated the PR to just downgrade #[inline(always)] to #[inline] in a number of cases then.

@alexcrichton
Copy link
Member Author

r? @sfackler

@rust-highfive rust-highfive assigned sfackler and unassigned brson Jul 22, 2017
@sfackler
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jul 22, 2017

📌 Commit 53d8b1d has been approved by sfackler

@bors
Copy link
Contributor

bors commented Jul 22, 2017

⌛ Testing commit 53d8b1d with merge f8d485f...

bors added a commit that referenced this pull request Jul 22, 2017
std: Cut down #[inline] annotations where not necessary

This PR cuts down on a large number of `#[inline(always)]` and `#[inline]`
annotations in libcore for various core functions. The `#[inline(always)]`
annotation is almost never needed and is detrimental to debug build times as it
forces LLVM to perform inlining when it otherwise wouldn't need to in debug
builds. Additionally `#[inline]` is an unnecessary annoation on almost all
generic functions because the function will already be monomorphized into other
codegen units and otherwise rarely needs the extra "help" from us to tell LLVM
to inline something.

Overall this PR cut the compile time of a [microbenchmark][1] by 30% from 1s to
0.7s.

[1]: https://gist.github.com/alexcrichton/a7d70319a45aa60cf36a6a7bf540dd3a
@bors
Copy link
Contributor

bors commented Jul 22, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: sfackler
Pushing f8d485f to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants