Prefetch some queries used by the metadata encoder

[Zoxc]

This brings the time for metadata encoding and writing for syntex_syntax from 1.338s to 0.997s with 6 threads in non-incremental debug mode.

r? @Mark-Simulacrum

[Zoxc]

I did some more tuning and brought the time for metadata encoding and writing down to 0.561.

@michaelwoerister Do you know why the incremental test failed here given that this PR doesn't change dependencies?

[michaelwoerister]

@michaelwoerister Do you know why the incremental test failed here given that this PR doesn't change dependencies?

I don't. The change doesn't look like should break that test.

[Zoxc]

Looks like we don't check queries which did not execute, and this caused some promoted_mir queries to execute.

[Mark-Simulacrum]

I am feeling uncertain about this PR. I would appreciate getting some wider feedback (not sure from who, maybe @michaelwoerister)... it feels like while it does give us some good wins, it feels somewhat fragile (i.e., depends on how metadata encoding works pretty closely).

I would rather see us explore making metadata encoding itself more parallel -- IIRC, the basic idea with encoding is a bunch of arrays representing trait impls, MIR, etc. -- maybe we can instead make constructing those be parallel?

[Mark-Simulacrum]

Could this commit be fleshed out with some description of why this is done? (i.e., in the commit message ideally)?

Right now it looks like presumably it's to make sure the exported_symbols query can fallback on the parallel MIR optimization in the last commit... but I'm not sure.

[Mark-Simulacrum]

Ah, so was this why the previous commit moved exported symbols later?

[Zoxc]

Yes. It's moved later to give more time for prefetching to happen.

[Zoxc]

I would rather see us explore making metadata encoding itself more parallel -- IIRC, the basic idea with encoding is a bunch of arrays representing trait impls, MIR, etc. -- maybe we can instead make constructing those be parallel?

I'd like to remove the existing metadata and all related code and instead use the incremental query cache for both metadata and incremental compilation so I don't really want to put any effort into refactoring the existing code.

[Mark-Simulacrum]

Should we then not land this either? Feels like the 0.4 second win is nice but not huge, and presumably would be less in incremental mode (more data to load?).

I feel like replacing metadata with incremental query cache is a pretty far reaching goal though -- maybe worth trying to polish metadata into better shape in the mean time? But I can see us not wanting to spend time on it. Obviously out of scope for this PR.

I guess I'm not opposed to landing this PR -- but I would like to see the first review comment addressed (expanding on the commit).

[michaelwoerister]

Here are some thoughts:

• The changes seem relatively safe as far as correctness is concerned (although I would add a comment that tcx.dep_graph.with_ignore() is only safe because query results aren't accessed).
• Generally, doing prefetching in a parallel setting also makes sense.
• However, the PR does add a bit of complexity and duplicates some logic, and
• we only have one performance number of one crate (that is known to be a bit of an edge case) in one compilation mode from a single machine without context (e.g. by what percentage did the end-to-end compile time for the crate change). So we don't have a lot of data to base this decision on; and we won't get more even after merging (at least not from perf.rlo).

So I'm on the fence on whether I think this is worth the trouble or not. Since the changes are safe and can be easily reverted, I'd say it's OK to merge but maybe with more comments, i.e.:

• marking the duplicated logic as such and referring to the respective other occurrences that need to be kept in sync).
• adding a comment that this prefetching is non-essential and can just be removed if it causes trouble or has detrimental effects.
• adding a comment about tcx.dep_graph.with_ignore()

[Mark-Simulacrum]

I am also not opposed to merging with more comments.

[joelpalmer]

Triaged

[Zoxc]

I added some comments and make the code use assert_ignored instead of with_ignore.

[Mark-Simulacrum]

The changes look reasonable, but I cannot review the prefetching of the MIR bodies, as I'm not familiar enough with the code that'll be using that prefetching later on (nor with the relevant queries). I'm a little worried by the amount of code that is needed for prefetching there, too, particularly as it seems likely to not get updated over time (given the complex conditionals especially) to fit exactly what we need.

With that in mind, let's try r? @matthewjasper perhaps? I'm not sure if you're the best person for the optimized/promoted MIR queries, which seem to be dominant in that convoluted code.

[bors]

☔ The latest upstream changes (presumably #70118) made this pull request unmergeable. Please resolve the merge conflicts.

[matthewjasper]

@bors r+

[bors]

📌 Commit 027c8d9 has been approved by matthewjasper