rustdoc: Use ThinVec in a few places

[camelid]

Almost every crate has no primitives and no keywords defined in it, so
using ThinVec should make some types smaller.

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[camelid]

r? @ghost (also, this is a T-rustdoc PR, but it includes commits from a PR that modifies the compiler)

[camelid]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit b98549512944f6ac37635db69053a1f609b24e86 with merge b9fd9ecb9bab4884a084e182d2af487064b59de3...

[bors]

☀️ Try build successful - checks-actions
Build commit: b9fd9ecb9bab4884a084e182d2af487064b59de3 (b9fd9ecb9bab4884a084e182d2af487064b59de3)

[rust-timer]

Queued b9fd9ecb9bab4884a084e182d2af487064b59de3 with parent 97717a5, future comparison URL.

[rust-timer]

Finished benchmarking try commit (b9fd9ecb9bab4884a084e182d2af487064b59de3): 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
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[jyn514]

This is a good idea. I'll try doing this in #83833.

[camelid]

Wow, that was actually a bigger improvement than I expected!

[pickfire]

Why not make it thinner by combining this two into one pointer?

[jyn514]

What do you mean? These are stored in the ThinVec, on the heap, not on the stack.

[pickfire]

Yes, but since both of them are as rare, so we can just combine both into one pointer rather than two right? But yeah, if one is needed then we need the pointer already.

Only useful if both are always together at the same time.

[camelid]

It's possible that combining them into one boxed field would make it smaller, but

1. that would require code changes, and the slight perf improvement is likely not worth it;
2. there probably won't be much of a perf improvement because padding may take up the space anyway.

[pickfire]

Wow, that was actually a bigger improvement than I expected!

I can't see much improvements, the benchmark seemed neutral. How do you all see that?

Wait, do you mean all those -0.2%?

[jyn514]

@bors r+ rollup=never

[bors]

📌 Commit 3ea8ebc has been approved by jyn514

[bors]

⌛ Testing commit 3ea8ebc with merge 8b53ec6...

[bors]

☀️ Test successful - checks-actions
Approved by: jyn514
Pushing 8b53ec6 to master...

[camelid]

Interestingly, the perf run after merge didn't show the instruction count improvements that the earlier perf run showed. Perhaps that could be due to the changes that were made in #83821 after the earlier perf run?

However, there did seem to be some max-rss improvements in regex-doc and clap-rs-doc. Though I don't feel confident enough in my knowledge of rustc-perf to know if they're spurious improvements or not.