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.

Sign up for GitHub

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

Use sort_by_cached_key when the key function is not trivial/free #55821

Merged
merged 1 commit into from
Nov 30, 2018
Merged

Use sort_by_cached_key when the key function is not trivial/free #55821

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/librustc/middle/resolve_lifetime.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1573,7 +1573,7 @@ impl<'a, 'tcx> LifetimeContext<'a, 'tcx> {
.collect();

// ensure that we issue lints in a repeatable order
def_ids.sort_by_key(|&def_id| self.tcx.def_path_hash(def_id));
def_ids.sort_by_cached_key(|&def_id| self.tcx.def_path_hash(def_id));
Copy link
Contributor

Choose a reason for hiding this comment

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

As you noted, I think this is already cached -- it's something we do a lot in incremental. You agree, @michaelwoerister ?

Copy link
Member

Choose a reason for hiding this comment

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

It's cached, yes, but still not entirely trivial. I.e. it has to do the local/upstream crate dispatch and for upstream DefIds it has to go through a number of function calls:

rust/src/librustc/ty/context.rs

Line 1325 in 780658a

pub fn def_path_hash(self, def_id: DefId) -> hir_map::DefPathHash {

So, I can imagine this being a win for sorting where each key might be compared against multiple times.


for def_id in def_ids {
debug!(
Expand Down
2 changes: 1 addition & 1 deletion src/librustc/traits/object_safety.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -409,7 +409,7 @@ impl<'a, 'tcx> TyCtxt<'a, 'tcx, 'tcx> {
.collect::<Vec<_>>();

// existential predicates need to be in a specific order
associated_types.sort_by_key(|item| self.def_path_hash(item.def_id));
associated_types.sort_by_cached_key(|item| self.def_path_hash(item.def_id));
Copy link
Contributor

Choose a reason for hiding this comment

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

Also here, of course


let projection_predicates = associated_types.into_iter().map(|item| {
ty::ExistentialPredicate::Projection(ty::ExistentialProjection {
Expand Down
2 changes: 1 addition & 1 deletion src/librustc_mir/monomorphize/partitioning.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -985,7 +985,7 @@ fn collect_and_partition_mono_items<'a, 'tcx>(
output.push_str(" @@");
let mut empty = Vec::new();
let cgus = item_to_cgus.get_mut(i).unwrap_or(&mut empty);
cgus.as_mut_slice().sort_by_key(|&(ref name, _)| name.clone());
cgus.as_mut_slice().sort_by_cached_key(|&(ref name, _)| name.clone());
Copy link
Contributor

Choose a reason for hiding this comment

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

This might make sense. Not sure what type name has here... :)

cgus.dedup();
for &(ref cgu_name, (linkage, _)) in cgus.iter() {
output.push_str(" ");
Expand Down