Monomorphize calculate_dtor instead of using function pointers

[bugadani]

Change calculate_dtor to avoid dynamic dispatching. This change allows the empty functions to be optimized away.

Based on the discussion in #77754 (comment), the performance impact of this change was measured.

Perf run results: https://perf.rust-lang.org/compare.html?start=7bc5839e99411aad9061a632b62075d1346cbb3b&end=ffec759ae9bbc4d6d2235ff40ade6723a85bc7cc

[rust-highfive]

r? @ecstatic-morse

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

[ecstatic-morse]

The input closure is called in a loop for each relevant impl and is trivial for at least one plausibly hot call (adt_destructor). It's possible that this will speed things up enough to matter.

@bors try
@rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit fc17e91e14701a76c404bc05e44807db91e7261a with merge ffec759ae9bbc4d6d2235ff40ade6723a85bc7cc...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: ffec759ae9bbc4d6d2235ff40ade6723a85bc7cc (ffec759ae9bbc4d6d2235ff40ade6723a85bc7cc)

[rust-timer]

Queued ffec759ae9bbc4d6d2235ff40ade6723a85bc7cc with parent 7bc5839, future comparison URL.

[rust-timer]

Finished benchmarking try commit (ffec759ae9bbc4d6d2235ff40ade6723a85bc7cc): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[bugadani]

@ecstatic-morse could you please take a look at the results? Do you think this change would make sense? Thanks!

[ecstatic-morse]

Seems to be a very tiny win, only enough to matter on very small crates. Still, using a trait object here is saving like two monomorphizations, so I think a generic parameter is fine.

@bors rollup-
@bors r+

[bors]

📌 Commit 0d27b76 has been approved by ecstatic-morse

[bors]

⌛ Testing commit 0d27b76 with merge a6aa039311c05d0f43e07f49a770cdac914daf0e...

[bors]

💔 Test failed - checks-azure

[rust-log-analyzer]

Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

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 @rust-lang/infra. (Feature Requests)

[pietroalbini]

Seems like a spurious failure.

@bors retry

[bors]

⌛ Testing commit 0d27b76 with merge 2d6eccd...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: ecstatic-morse
Pushing 2d6eccd to master...

[Mark-Simulacrum]

This ended up as a 1% regression on the deeply-nested-async benchmark -- do we think that's likely to be spurious? The original perf results don't show this regression. Wall times also seem up across the board, but that could be noise.

I am somewhat surprised by these results -- this PR looks like it shouldn't cause such significant effects. That said, it does seem like the extra inlining here could end up harmful in the end perhaps? I am inclined to revert it (or at least benchmark a revert).

[bugadani]

There is always a chance that this screwed up cache alignment, in combination with another PR that interacts with it. I wonder if a PR between the perf run and the merge pushed something out of alignment, maybe? If that is possible, I think this PR could cause unnecessary noise and should be reverted. But it would be nice to know for sure, what happened.