rendering blocked by loading _framework/dotnet.5.0.4.js (Blazor WASM)
Categories
(Core :: JavaScript: WebAssembly, defect, P3)
Tracking
()
People
(Reporter: ewansinclair91, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Steps to reproduce:
Head to 'https://app.tevent.com' in Firefox, and watch the animation that renders while the page loads
Actual results:
You will see the loading animation is choppy and halts entirely while the browser loads '_framework/dotnet.5.0.4.js' which is a part of the Blazor WASM framework.
Expected results:
Ideally this could be loaded in the background while the page rendering continues
| Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Javascript: WebAssembly' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•4 years ago
|
||
Yeah... We compile functions on background threads but the module prefix is parsed and interpreted on the foreground thread I think, so that may be part of the problem. It would be worth it to profile this to see where the time goes when the animation pauses. There's always the chance we have some O(n^2) problem lurking.
Comment 3•4 years ago
|
||
There's a five-second window after loading where it appears that nearly all the time (85%) is being spent in the blazor interpreter itself and no new events are processed. Plausibly this is some sort of initialization. I get roughly the same result with tiering, just with ion, or just with baseline. (FF90, Linux)
Chromium on this system has much the same behavior but the blazor interpreter runs solid for only about 1.5s (if i read the Chromium profiler correctly), so the visual impression is much better.
There's always the chance that Chromium is fed different content, but assuming not then we either have a serious pessimization of something here or an outright bug, though likely not in the compiler per se since the different compilers show the same behavior. It would have to be something in our runtime architecture: stubs, linking, indirect calls, table accesses, or similar; could be related to JS of course.
Updated•4 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 4•3 years ago
|
||
The animation is no longer there.
Description
•