-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Tweak query code for performance #56613
Conversation
@@ -58,6 +60,26 @@ extern crate rustc_cratesio_shim; | |||
|
|||
pub use rustc_serialize::hex::ToHex; | |||
|
|||
#[macro_export] | |||
macro_rules! likely { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This macro isn't used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It gets used in #56614. Might as well add them both
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't look at that PR :)
@bors try |
Tweak query code for performance Split from #56509 r? @michaelwoerister
if self.opts.debugging_opts.self_profile || self.opts.debugging_opts.profile_json { | ||
let mut profiler = self.self_profiling.borrow_mut(); | ||
f(&mut profiler); | ||
if unlikely!(self.self_profiling_active) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LLVM already assigns reduced branch weights to branches postdominated by calls to cold functions, so I wouldn't expect this unlikely!()
to have an effect here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did find a case where it didn't though, so I used likely
and unlikely
just in case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd really like to have PGO for the Rust compiler at some point :)
☀️ Test successful - status-travis |
@rust-timer build c89a860 |
Success: Queued c89a860 with parent 9567a1c, comparison URL. |
Finished benchmarking try commit c89a860 |
@@ -159,6 +159,10 @@ impl Forest { | |||
self.dep_graph.read(DepNode::new_no_params(DepKind::Krate)); | |||
&self.krate | |||
} | |||
|
|||
pub fn untracked_krate<'hir>(&'hir self) -> &'hir Crate { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a warning comment here not to use this function and that it only exists for internal use with the dep-tracking system.
{ | ||
if let Err(cycle) = job.await(tcx, span) { | ||
return TryGetJob::JobCompleted(Err(cycle)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the following would be more readable:
if cfg!(parallel_queries) {
if let Err(cycle) = job.await(tcx, span) {
return TryGetJob::JobCompleted(Err(cycle));
}
} else {
// If we get here in non-parallel mode we know that we have cycle error.
let result = job.await(tcx, span);
debug_assert!(result.is_err());
return result;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That doesn't work since await
now has different signatures depending on cfg!(parallel_queries)
. I'll add the comment though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@@ -299,7 +310,7 @@ macro_rules! define_dep_nodes { | |||
/// Construct a DepNode from the given DepKind and DefPathHash. This | |||
/// method will assert that the given DepKind actually requires a | |||
/// single DefId/DefPathHash parameter. | |||
#[inline] | |||
#[inline(always)] | |||
pub fn from_def_path_hash(kind: DepKind, | |||
def_path_hash: DefPathHash) | |||
-> DepNode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can turn the assertion below into a debug_assertion
.
src/librustc/dep_graph/dep_node.rs
Outdated
pub fn new_no_params(kind: DepKind) -> DepNode { | ||
assert!(!kind.has_params()); | ||
assert!(!kind.has_params_inlined()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be turned into a debug_assertion
too.
src/librustc/dep_graph/dep_node.rs
Outdated
#[inline] | ||
pub fn is_input(&self) -> bool { | ||
#[inline(always)] | ||
pub fn is_input_inlined(&self) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are is_input
and has_params
split but not is_anon
and is_eval_always
? I'd prefer not to split them into two methods. Maybe, with some of the assertions in here turned into debug-assertions, a regular #[inline]
would suffice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is_anon
and is_eval_always
has uses where inlining them might not be beneficial. A regular #[inline]
does not suffice since these are large functions and LLVM won't inline them unless you tell it to. I use the *_inlined
variants for calls when LLVM can optimize it all away.
I want to turn these properties into associated constants anyway, but that is blocked on #56462.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think switching to debug_assertions
will remove most of the hot calls to those functions. Since they might be replaced soon anyway, I'd prefer not to split the functions in order to avoid churn. You can just mark them as #[inline(always)]
if performance is bad otherwise.
Thanks, @Zoxc! I left some comments. You could also try to turn |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
📌 Commit 64d54e61b70245c0aa660c888c7545206ca872b1 has been approved by |
⌛ Testing commit 64d54e61b70245c0aa660c888c7545206ca872b1 with merge fd5abe90bc2c0934babdd742ace6d7618035d0e2... |
💔 Test failed - status-appveyor |
Hmm.. a crash, maybe |
@bors r=michaelwoerister |
📌 Commit f0adf5a has been approved by |
Tweak query code for performance Split from #56509 r? @michaelwoerister
☀️ Test successful - status-appveyor, status-travis |
Split from #56509
r? @michaelwoerister