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

Performance audit, Spring 2017 #41469

Merged
merged 8 commits into from Apr 22, 2017

Conversation

Projects
None yet
7 participants
@arielb1
Copy link
Contributor

arielb1 commented Apr 22, 2017

Fix up some quite important performance "surprises" I've found running callgrind on rustc.

arielb1 added some commits Apr 19, 2017

remove cleanup branches to the resume block
This improves LLVM performance by 10% lost during the shimmir transition.
avoid calling `mk_region` unnecessarily
this improves typeck & trans performance by 1%. This looked hotter on
callgrind than it is on a CPU.
short-cut SharedCrateContext::layout_of
That method is *incredibly* hot, so this ends up saving 10% of trans
time.

BTW, we really should be doing dependency tracking there - and possibly be
taking the respective perf hit (got to find a way to make DTMs fast), but
`layout_cache` is a non-dep-tracking map.
cache attributes of items from foreign crates
this avoids parsing item attributes on each call to `item_attrs`, which takes
off 33% (!) of translation time and 50% (!) of trans-item collection time.
allocate less strings in `symbol_names`
this improves trans performance by *another* 10%.
add a cache to impl_polarity
this is another one of these things that looks *much* worse on valgrind.
bail out of selection when there are multiple surviving candidates
In some cases (e.g. <[int-var] as Add<[int-var]>>), selection can turn up
a large number of candidates. Bailing out early avoids O(n^2) performance.

This improves item-type checking time by quite a bit, resulting in ~2% of total
time-to-typeck.
@arielb1

This comment has been minimized.

Copy link
Contributor

arielb1 commented Apr 22, 2017

moved over from #41410

@bors r=eddyb

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Apr 22, 2017

📌 Commit a660ad8 has been approved by eddyb

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Apr 22, 2017

r? @pnkfelix

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

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Apr 22, 2017

💡 This pull request was already approved, no need to approve it again.

  • There's another pull request that is currently being tested, blocking this pull request: #41431
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Apr 22, 2017

📌 Commit a660ad8 has been approved by eddyb

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Apr 22, 2017

⌛️ Testing commit a660ad8 with merge 252d3da...

bors added a commit that referenced this pull request Apr 22, 2017

Auto merge of #41469 - arielb1:rustc-spring-cleaning, r=eddyb
Performance audit, Spring 2017

Fix up some quite important performance "surprises" I've found running callgrind on rustc.
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Apr 22, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing 252d3da to master...

@bors bors merged commit a660ad8 into rust-lang:master Apr 22, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@bluss bluss added the relnotes label Apr 23, 2017

@leonardo-m

This comment has been minimized.

Copy link

leonardo-m commented May 6, 2017

I am using:
nightly-x86_64-pc-windows-gnu rustc 1.19.0-nightly (f4209651e 2017-05-05)

I was unable to install the 2017-05-04 nightly because of a known issue.

The 2017-05-03 Nightly has shown a performance regression when I compile with just "rustc --emit=metadata". Perhaps a commit has removed the performance enhancement of this Performance audit. Before I open a regression report perhaps @arielb1 could take a quick look at the timings.

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented May 6, 2017

@leonardo-m It's best to file a regression report, since this will likely go unnoticed and is also hard to prioritize. Please include the code sample that you used, since that will make it easier for others to diagnose the regression.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment