rustdoc: Rearrange Item/ItemInner.
#138927
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
A-rustdoc-json
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 25, 2025
…, r=<try> rustdoc: Rearrange `Item`/`ItemInner`. The `Item` struct is 48 bytes and contains a `Box<ItemInner>`; `ItemInner` is 104 bytes. This is an odd arrangement. Normally you'd have one of the following. - A single large struct, which avoids the allocation for the `Box`, but can result in lots of wasted space in unused parts of a container like `Vec<Item>`, `HashSet<Item>`, etc. - Or, something like `struct Item(Box<ItemInner>)`, which requires the `Box` allocation but gives a very small Item size, which is good for containers like `Vec<Item>`. (`Vec<Box<Item>>` would also work.) `Item`/`ItemInner` currently gets the worst of both worlds: it always requires a `Box`, but `Item` is also pretty big and so wastes space in containers. It would make sense to push it in one direction or the other. This commit does the second option, giving a tiny `Item`. r? `@ghost`
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (ffdc630): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -1.4%, secondary -0.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 1.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 777.441s -> 777.041s (-0.05%) |
rustbot
removed
the
S-waiting-on-perf
The `Item` struct is 48 bytes and contains a `Box<ItemInner>`; `ItemInner` is 104 bytes. This is an odd arrangement. Normally you'd have one of the following. - A single large struct, which avoids the allocation for the `Box`, but can result in lots of wasted space in unused parts of a container like `Vec<Item>`, `HashSet<Item>`, etc. - Or, something like `struct Item(Box<ItemInner>)`, which requires the `Box` allocation but gives a very small Item size, which is good for containers like `Vec<Item>`. `Item`/`ItemInner` currently gets the worst of both worlds: it always requires a `Box`, but `Item` is also pretty big and so wastes space in containers. It would make sense to push it in one direction or the other. rust-lang#138916 showed that the first option is a regression for rustdoc, so this commit does the second option, which improves speed and reduces memory usage.
nnethercote
force-pushed
the
rearrange-Item-ItemInner
branch
from
4312081 to
ffee55c
Compare
|
Good doc perf results: icounts don't change much, but cycles, wall-time and max-rss all show improvements. (This is a case where enabling "Show non-relevant results" is worthwhile.) I also tried merging |
GuillaumeGomez
approved these changes
Mar 27, 2025
|
Great catch! Funny that no one noticed it. All good for me, thanks! @bors r+ rollup=iffy |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing ecb170a (parent) -> 217693a (this PR) Test differencesShow 32935 test diffsStage 1
Stage 2
(and 16364 additional test diffs) Additionally, 16471 doctest diffs were found. These are ignored, as they are noisy. Job group index
|
|
Finished benchmarking commit (217693a): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -0.7%, secondary 1.9%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 779.46s -> 778.49s (-0.12%) |
|
The post-merge perf CI results (slight perf wins overall) were less good than the pre-merge results (clear perf wins overall), for no obvious reason. (Only the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
Itemstruct is 48 bytes and contains aBox<ItemInner>;ItemInneris 104 bytes. This is an odd arrangement. Normally you'dhave one of the following.
A single large struct, which avoids the allocation for the
Box, butcan result in lots of wasted space in unused parts of a container like
Vec<Item>,HashSet<Item>, etc.Or, something like
struct Item(Box<ItemInner>), which requires theBoxallocation but gives a very small Item size, which is good forcontainers like
Vec<Item>.Item/ItemInnercurrently gets the worst of both worlds: it alwaysrequires a
Box, butItemis also pretty big and so wastes space incontainers. It would make sense to push it in one direction or the
other. #138916 showed that the first option is a regression for rustdoc,
so this commit does the second option, which improves speed and reduces
memory usage.
r? @GuillaumeGomez