Closed Bug 1709604 Opened 4 years ago Closed 3 years ago

rendering blocked by loading _framework/dotnet.5.0.4.js (Blazor WASM)

Categories

(Core :: JavaScript: WebAssembly, defect, P3)

Firefox 89
x86_64
All
defect

Tracking

()

RESOLVED INCOMPLETE

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

Type: enhancement → defect

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.

Component: Untriaged → Javascript: WebAssembly
Product: Firefox → Core

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.

Severity: -- → N/A
Type: defect → enhancement
Priority: -- → P3

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → x86_64
Severity: N/A → S2
Type: enhancement → defect

The animation is no longer there.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.