This bug has been spotted by @est31:
Rustdoc search-index.js regression
There seems to be a regression in how quickly rustdoc pages load.
Just do the following with Firefox 64.0:
- visit https://doc.rust-lang.org/1.32.0/core/convert/trait.TryFrom.html
- open network tab in developer console
- reload the page with cold caches (ctrl+shift+R)
- At the bottom there is a number
load: XXX in pink
Now do the same procedure for the nightly docs https://doc.rust-lang.org/1.32.0/core/convert/trait.TryFrom.html
What I see is a difference in the pink load time. For nightly, it's 466 ms and for stable, it's 1.6 seconds.
Now let's dig a little bit deeper. There is a "performance analysis" tab in the Firefox developer tools.
Here you can see what the browser is doing to load a page.
If you visit the nightly page, there is a clear yellow bar with 597 ms wait time for me. If you click this bar you can see that it's spending in search-index.js. If you visit the stable page, you have to search a bit for the yellow bar of search-index.js but if you find it, it's much much smaller. Only 52 ms!
So I'd claim that the regression in load time is due to a parsing time regression for search-index.js.
I can experience the bug on a personal project that uses nightly as well, and here it's far more grave (multiple seconds to wait), most probably because it's a bigger project.
I experience this bug only since a few days, thus I believe this to be a regression of this PR: #56869
One idea I had is to use an array instead of creating a lot of variables. It'll certainly take a bit more space but I think it'll allow to remove the parsing performance issue.
This bug has been spotted by @est31:
One idea I had is to use an array instead of creating a lot of variables. It'll certainly take a bit more space but I think it'll allow to remove the parsing performance issue.