-
Notifications
You must be signed in to change notification settings - Fork 13.3k
librustdoc
: more impl fmt::Display
#138455
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
librustdoc
: more impl fmt::Display
#138455
Conversation
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
This is intentional, I'm pulling in latest version of |
Perf is neutral locally, but I'll request a run on CI just to be sure. |
src/librustdoc/html/markdown.rs
Outdated
&added_classes, | ||
let s = format!( | ||
"\n{}", | ||
highlight::render_example_with_highlighting( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this change is good considering we need to allocate a string in any case but relying on format!
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will end up behaving exactly the same. It will construct the string piece-by-piece.
It would only matter if we used String::with_capacity
, otherwise .push
ing into a string directly, or using format!()
, are the same in terms of reallocations and such.
(maybe I'm missing something?)
src/librustdoc/html/highlight.rs
Outdated
@@ -6,16 +6,17 @@ | |||
//! Use the `render_with_highlighting` to highlight some rust code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same in this file: I don't expect any improvement in performance considering it's always pushing into a string and it makes the code more complex.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point of this PR in itself isn't performance.
My end-goal is to try to make ALL the rendering lazy, and then we could ideally write into a BufWriter
that wraps the actual file, instead of writing everything to a String
first, and then to the file system.
I do believe that that would be good for performance, because it should minimize the number of reallocs needed for rendering a single file. And maybe we could reuse the underlying buffer from BufWriter
, which would be even better.
But such a change would be huge and I don't want to do it in one PR, so in the meanwhile I'm trying to put out small PRs that make progress towards that goal without hurting performance - so this PR being neutral in a perf run would be a success, as far as I'm concerned.
I also want to get rid of that write_str
helper I introduced in #136784, since it's very verbose (because it needs format_args!()
) and I intended it as a stopgap measure.
The only change to the code in this file (if you view the diff w/o whitespace) is the fmt::from_fn()
and extra indentation it causes, which isn't great, but I think that the removal of all the format_args!()
makes up for it. That's just my personal opinion, of course :)
Anyways, if you don't like the direction I'm going in let me know, and, obviously, feel free to close this PR if you think it's not improving the code at all! I'm thankful for the time you put into reviewing all my PRs 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with the rest of the changes. In highlight.rs
though a bit less.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I undid the unrelated changes in highlight.rs
, let me know if it's better now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry but still the same, for now I only see it as a code complexity increase for no gain. ^^'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay, was traveling 😁
Undid the changes in this file, will figure it out in the future.
f8f7bc2
to
f22e94c
Compare
f22e94c
to
cf9cf6b
Compare
☔ The latest upstream changes (presumably #139525) made this pull request unmergeable. Please resolve the merge conflicts. |
cf9cf6b
to
b51e696
Compare
b51e696
to
8dd1cbb
Compare
Looks all good now, thanks! Let's just run a perf check before r+. @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…ay, r=<try> `librustdoc`: more `impl fmt::Display` Continuation of rust-lang#137425 and rust-lang#136828 and rust-lang#136784 Working towards getting rid of the `write_str` helper r? `@GuillaumeGomez` (if you want!)
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (6f904d8): comparison URL. Overall result: no relevant changes - 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 benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 0.5%, secondary -2.5%)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 (primary 0.5%, secondary -2.5%)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: 781.063s -> 781.152s (0.01%) |
Confirmed that there are no perf changes, so rollup it is. Thanks! @bors r+ rollup |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#138455 (`librustdoc`: more `impl fmt::Display`) - rust-lang#139818 (Normalize ADT field in `find_tails_for_unsizing`) - rust-lang#139819 (Use `rust-cache` to speed-up `citool` compilation) - rust-lang#139824 (Remove safe remove) - rust-lang#139848 ( Reduce kw::Empty usage, part 5) - rust-lang#139859 (CI: rename MacOS runner) - rust-lang#139877 (Add warning comment to `Take::get_ref` and `Chain::get_ref`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#138455 - yotamofek:pr/rustdoc/more-impl-display, r=GuillaumeGomez `librustdoc`: more `impl fmt::Display` Continuation of rust-lang#137425 and rust-lang#136828 and rust-lang#136784 Working towards getting rid of the `write_str` helper r? `@GuillaumeGomez` (if you want!)
Continuation of #137425 and #136828 and #136784
Working towards getting rid of the
write_str
helperr? @GuillaumeGomez (if you want!)