[rustdoc] Box ItemKind to reduce the size of Item

[jyn514]

This brings the size of Item from

[src/librustdoc/lib.rs:103] std::mem::size_of::<Item>() = 536

to

[src/librustdoc/lib.rs:103] std::mem::size_of::<Item>() = 136

This is an alternative to #79967; I don't think it makes sense to make both changes.

Helps with #79103.

[rust-highfive]

Some changes occurred in intra-doc-links.

cc @jyn514

[rust-highfive]

r? @ollie27

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

[jyn514]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 1b6bb0c79853f4d96b91679f5a01cd6c79291ba8 with merge 5060bdc312fd830ad807a5d08d2f884ef1303a1c...

[bors]

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

[rust-timer]

Queued 5060bdc312fd830ad807a5d08d2f884ef1303a1c with parent 057937b, future comparison URL.

[rust-timer]

Finished benchmarking try commit (5060bdc312fd830ad807a5d08d2f884ef1303a1c): 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 modify labels: +S-waiting-on-review -S-waiting-on-perf

[jyn514]

Up to -1.7% on instructions, up to -3.1% on max-rss. The RSS numbers for rustdoc seem to be less variable than for rustc for some reason.

[jyn514]

r? @nnethercote maybe?

[pnkfelix]

Helps with #79103.

Is there a way you could measure how much it helps reduce the peak memory usage there?

[nnethercote]

Can you add a static assertion on the size to prevent future regressions? Something like this, which is a pattern used in various places in the compiler:

// `Item` is used a lot. Make sure it doesn't unintentionally get bigger.
#[cfg(target_arch = "x86_64")]
static_assert_size!(Item, 280);

r=me with that done.

Also, 280 bytes is still large. Most of the AST types in the compiler itself are less than 100 bytes. Which fields are big?

[jyn514]

@nnethercote you should have seen when I started, it was 784 bytes 😆 #79957 (comment)

This is all changing rather rapidly so I'm a little hesitant to put an assert since it will make rebasing harder. After rebasing over master the new change is from 616 to 216.

Also, 280 bytes is still large. Most of the AST types in the compiler itself are less than 100 bytes. Which fields are big?

[src/librustdoc/lib.rs:103] std::mem::size_of::<Span>() = 8
[src/librustdoc/lib.rs:103] std::mem::size_of::<Option<rustc_span::Symbol>>() = 4
[src/librustdoc/lib.rs:103] std::mem::size_of::<Attributes>() = 96
[src/librustdoc/lib.rs:103] std::mem::size_of::<Visibility>() = 40
[src/librustdoc/lib.rs:103] std::mem::size_of::<Box<ItemKind>>() = 8
[src/librustdoc/lib.rs:103] std::mem::size_of::<DefId>() = 8
[src/librustdoc/lib.rs:103] std::mem::size_of::<Option<Stability>>() = 16
[src/librustdoc/lib.rs:103] std::mem::size_of::<Option<rustc_attr::Deprecation>>() = 16
[src/librustdoc/lib.rs:103] std::mem::size_of::<Option<ConstStability>>() = 20

So most of the size is coming from Attributes, Visibility, and (Stability, Deprecation, ConstStability). The last three are from rustc directly. A way I thought of to reduce that size is to calculate them on demand with something like

enum ItemId {
    Real(DefId),
    Fake(usize),
}

impl Item {
  fn stability() -> Option<Stability> { ... }
}

and then always return None for fake items. The issue with that is it requires passing a TyCtxt into render, which I have code for, but is a pretty big invasive change.

I do not currently have ideas for reducing the size of Visibility or Attributes.

[jyn514]

Helps with #79103.

Is there a way you could measure how much it helps reduce the peak memory usage there?

Measuring this (imprecisely, with time -v, but better than nothing) gives Maximum resident set size (kbytes): 2060060 with this change and Maximum resident set size (kbytes): 2096996 without. So there was an improvement of about 37 MB.

FYI, all of these measurements are done with --features stm32h743, which is the smallest set of features you can add and still compile stm32h7. There are a bunch of others I can add to slow it down.

[jyn514]

This now brings the size from 536 to 136 bytes.

[jyn514]

I added the static assertion.

@bors r=nnethercote

[bors]

📌 Commit 5fce0dd has been approved by nnethercote

[jyn514]

@bors rollup=never

[bors]

⌛ Testing commit 5fce0dd with merge 158f8d0...

[bors]

☀️ Test successful - checks-actions
Approved by: nnethercote
Pushing 158f8d0 to master...