You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[tracking-ish issue] Doc pages are very slow to render #55900
the https://doc.rust-lang.org/std/iter/trait.Iterator.html page(and only that page?) seems to have a broken search bar that manifests as infinite? loading and high CPU usage in both Chrome and firefox, across stable, beta, nightly, and local versions.
The HTML for that page is currently about 12.5MB thanks to #51885. We're now rendering a copy of every trait method for every impl. We could revert #51885 or only render methods that have documentation in the impl.
Reacted by crumblingstatue, Sam, leo60228 and LukeLin
Just to confirm this issue: I wanted to add that even loading that page is next to impossible on Safari. It takes a very long time, and after it loads, scrolling is so slow that the page is next to useless. I often have to switch to Firefox (my secondary browser) only to read this specific page in the docs.
Reacted by crumblingstatue, Harrison McCullough and Stijn
Not only is it very slow to render initially, but due to the sheer amount of content on the page, it is also very sluggish to scroll through it on my system.
I also agree that we should show less information by default. A 12.5 MB doc page for a single item sounds ridiculous.
I'd very much prefer if implementors were just listed plainly like so: Implementors: std::ascii::EscapeDefault, EscapeDebug, std::char::EscapeDefault, EscapeUnicode, ToLowercase, ToUppercase, ..., with them being links so you can click on them to go to their doc page.
This amount of duplication is a lot of wasted data. It makes the documentation bloated and slow.
Reacted by Shotaro Yamada, kennytm, Andrew Gallant, thezjy, Dmitry Murzin, Arne Keller, Alex and Kevin M Granger
Also it would be good to fix this as fast as possible (I have not idea how still a newbie), Iterator are a lot used and be able to read the doc is primordial.
Freeze on Chrome Version 70.0.3538.110 (Build officiel) (64 bits)
Load quite fast on Firefox 63.0.3 (64 bits) ;)
Just tried beta and nightly in incognito and it works about the same. The page doesn't freeze or anything, but scrolling is a bit laggy. Chrome uses ~30-40% cpu when scrolling.
I think this patch is live though, because nightly shows some loading text while the sections are loaded instead of instantly trying to render?
yeah, that doesn't freeze but the page still load tons of information, is it possible to have the page that only load what user required, for example, a plus bottom that will only load content when opened ? That would allow to see method, without load everything.
Also, all theses informations are them really needed ? Why did we do this change ?
The rendering was slow in any case so whatever changes we want to perform afterwards, we'll still gain from them. We're debating about what information could/should be removed on the pages alongside making the HTML/JS lighter. It's moving forward.
Speaking of doc performance, you might want to fix the server's config to compress html documents. Those 13MB are 692K gzip'd, 74K brotli'd.
We already have automatic compression configured on the CloudFront side, but CloudFront won't compress files bigger than 10MB, so fixing this is not a simple configuration change.
Can I suggest a minimal change, as far as I can see without downsides, that should significantly reduce the size of the Iterator doc page:
In the Implementors and Implementations on Foreign Types sections, only show methods that appear in the impl block for that type. This has the benefit of
Reducing the size of the Iterator page, and other large trait documentation pages.
Retaining documentation on the impl blocks and functions in the impl blocks.
Indicating which provided methods are overridden.
Making the documentation match the structure of the code being documented.
Being a small change that can be easily backed out if issues arise.
What this would look like for the Read trait:
This should be an easy change to make so I'll try and have a PR ready soon so we can see what impact it would have on page sizes and load times.
Reacted by Eadyn, Jack O'Connor, phiresky, Jack Wrenn, Tim Neumann, Connie Hilarides, Colin, Scott Steele, Bryant Rockoff, Vitaly Shukela and 5 more
Reacted by Diana, memoryruins, Mackenzie Hauck, Stargateur, Jean Mertz, Clément Renault, Peter Asztalos, Benjamin Levy, Eadyn, Carl Fredrik Samson and 10 more
@ebarnard 's iterator docs: loads nearly immediately on laptop 🎉, and it scrolls smoothly without page flickering or laptop fans becoming loud. It loaded quickly on my phone too :)
It appears to make docs pages clearer and easier to navigate in general.
Little update: I think I'll investigate wasm at some point and see if it improves the situation. But first, I want to check if there is a way to improve how we store the information in the search-index.js file.
I think this issue should be closed. The original regression caused by #51885 has long since been fixed by #61505. I think we can track specific performance problems in dedicated issues like #56545.
Activity
ollie27 commentedon Nov 12, 2018
The HTML for that page is currently about 12.5MB thanks to #51885. We're now rendering a copy of every trait method for every impl. We could revert #51885 or only render methods that have documentation in the impl.
JeanMertz commentedon Nov 17, 2018
Just to confirm this issue: I wanted to add that even loading that page is next to impossible on Safari. It takes a very long time, and after it loads, scrolling is so slow that the page is next to useless. I often have to switch to Firefox (my secondary browser) only to read this specific page in the docs.
crumblingstatue commentedon Dec 4, 2018
Not only is it very slow to render initially, but due to the sheer amount of content on the page, it is also very sluggish to scroll through it on my system.
I also agree that we should show less information by default. A 12.5 MB doc page for a single item sounds ridiculous.
I'd very much prefer if implementors were just listed plainly like so:
Implementors: std::ascii::EscapeDefault, EscapeDebug, std::char::EscapeDefault, EscapeUnicode, ToLowercase, ToUppercase, ..., with them being links so you can click on them to go to their doc page.This amount of duplication is a lot of wasted data. It makes the documentation bloated and slow.
Stargateur commentedon Dec 5, 2018
Also it would be good to fix this as fast as possible (I have not idea how still a newbie), Iterator are a lot used and be able to read the doc is primordial.
Freeze on Chrome Version 70.0.3538.110 (Build officiel) (64 bits)
Load quite fast on Firefox 63.0.3 (64 bits) ;)
GuillaumeGomez commentedon Dec 5, 2018
The PR is open and waiting for reviews.
nocduro commentedon Jan 8, 2019
Has this been deployed? I'm still having really sluggish performance on https://doc.rust-lang.org/std/iter/trait.Iterator.html
Related issue #57281
steveklabnik commentedon Jan 8, 2019
nocduro commentedon Jan 8, 2019
Just tried beta and nightly in incognito and it works about the same. The page doesn't freeze or anything, but scrolling is a bit laggy. Chrome uses ~30-40% cpu when scrolling.
I think this patch is live though, because nightly shows some loading text while the sections are loaded instead of instantly trying to render?
Stargateur commentedon Jan 8, 2019
yeah, that doesn't freeze but the page still load tons of information, is it possible to have the page that only load what user required, for example, a plus bottom that will only load content when opened ? That would allow to see method, without load everything.
Also, all theses informations are them really needed ? Why did we do this change ?
GuillaumeGomez commentedon Jan 8, 2019
The rendering was slow in any case so whatever changes we want to perform afterwards, we'll still gain from them. We're debating about what information could/should be removed on the pages alongside making the HTML/JS lighter. It's moving forward.
56 remaining items
GuillaumeGomez commentedon Jun 3, 2019
Arf sorry, I kept reading
docs.rsinstead ofdoc.rust-lang.org...emilyalbini commentedon Jun 3, 2019
We already have automatic compression configured on the CloudFront side, but CloudFront won't compress files bigger than 10MB, so fixing this is not a simple configuration change.
ebarnard commentedon Jun 3, 2019
Can I suggest a minimal change, as far as I can see without downsides, that should significantly reduce the size of the Iterator doc page:
In the Implementors and Implementations on Foreign Types sections, only show methods that appear in the
implblock for that type. This has the benefit ofimplblocks and functions in theimplblocks.What this would look like for the

Readtrait:This should be an easy change to make so I'll try and have a PR ready soon so we can see what impact it would have on page sizes and load times.
ebarnard commentedon Jun 3, 2019
A set of Rust stdlib docs build with this change are available here.
The
Iteratordoc page is now 724kB.memoryruins commentedon Jun 3, 2019
Thank you for trying these changes and providing a demo!
Immediate impression:
except causes my mobile browser to become unresponsive and crash.
It appears to make docs pages clearer and easier to navigate in general.
Another example trait page that should benefit, which I'm unable to load on my laptop:
https://docs.rs/uom/0.23.1/uom/trait.Conversion.html
GuillaumeGomez commentedon Jun 4, 2019
@ebarnard: Looks great! Can you open a PR with your changes please? It'll also allow to see if other people like this change or not.
ebarnard commentedon Jun 4, 2019
@GuillaumeGomez It's open at #61505
Rollup merge of rust-lang#61505 - ebarnard:doc-shrink, r=GuillaumeGomez
Rollup merge of rust-lang#61505 - ebarnard:doc-shrink, r=GuillaumeGomez
GuillaumeGomez commentedon Apr 16, 2020
Little update: I think I'll investigate wasm at some point and see if it improves the situation. But first, I want to check if there is a way to improve how we store the information in the
search-index.jsfile.ollie27 commentedon Apr 16, 2020
I think this issue should be closed. The original regression caused by #51885 has long since been fixed by #61505. I think we can track specific performance problems in dedicated issues like #56545.