Fixing #95444 by only displaying passes that take more than 5 millise…

[randomicon00]

As discussed in #95444, I have added the code to test and only display prints that are greater than 5 milliseconds.

r? @jyn514

[jyn514]

I bo longer have bors privileges.

r? @rylev

[jyn514]

Ah, apparently Ryan doesn't either. Maybe

r? @wesleywiser

would be a good fit?

[jyn514]

... I think only the PR author can reassign the reviewer.

[randomicon00]

Done.
r? @wesleywiser

[klensy]

For some reason i can't comment on original issue, so will here.

Help for this flag says, that: time-passes=val -- measure time of each rustc pass (default: no), so it should print time for each pass. Forcing it to print only passes filtered by some hardcoded value will break that contract.

[randomicon00]

@klensy Your comment makes sense.
As I don't have a full understanding of the source code, can we please get the opinion of @jyn514? Thanks.

[jyn514]

We can just update the documentation to reflect the new behavior. I'm open to being convinced this isn't the right change but I don't think the comment is very compelling.

[jyn514]

Oh, we should probably include all passes that increase memory though, e.g. this one would be missed if we only go by CPU time:

time:   0.002; rss:   49MB ->   52MB (   +2MB)  parse_crate

[randomicon00]

@jyn514 sure. I will make an update later today or tomrrow.

[wesleywiser]

I'm not sure that a fixed cutoff like 5ms (or whatever) is going to be that useful in larger crates. As an extreme case, I doubt this would filter out any entries when compiling rustc_middle. However, switching to filtering based on a percentage of total time means there would be no output at all until the crate has finished compiling which seems very undesirable.

That being said, I don't really use -Ztime-passes at all so if people who are actually using it want this, I don't see any reason to hold this up.

[randomicon00]

@jyn514,@wesleywiser I've added the passes that increase memory. Any comments are, of course, welcome.
And thanks for providing me with this mentorship opportunity!

[randomicon00]

Just a friendly reminder that I am still available for any changes needed.

[wesleywiser]

There are a few tidy issues:

2022-03-30T21:23:39.1328047Z tidy error: /checkout/compiler/rustc_data_structures/src/profiling.rs:662: trailing whitespace
2022-03-30T21:23:39.1328594Z tidy error: /checkout/compiler/rustc_data_structures/src/profiling.rs:669: trailing whitespace
2022-03-30T21:23:39.1329092Z tidy error: /checkout/compiler/rustc_data_structures/src/profiling.rs:677: trailing whitespace

I think we can merge once these are taken care of. 🙂

[randomicon00]

@wesleywiser I completed the requested changes.

[wesleywiser]

Thanks, looks good! Would you mind squashing the commits together so we can merge?

[wesleywiser]

@bors r+

[bors]

📌 Commit e79ba76 has been approved by wesleywiser

[bors]

⌛ Testing commit e79ba76 with merge d60b4f5...

[bors]

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing d60b4f5 to master...

[rust-timer]

Finished benchmarking commit (d60b4f5): comparison url.

Summary: This benchmark run did not return any relevant results.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression