1724891 - Slow rendering discourse.mozilla.org

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Benyamin Limanto]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Browsing Discourse.Mozilla.org after browser start, waiting about 30s website to load, where on Chromium it only took 15s.

Seems JS website not performing Good on firefox, or probably my HW is too old(i7-2640m), but the problem is CrEdge and Chrome load very fast.

I've 16GB Ram, so RAM isn't problem.

NB : I tried to collect Performance Profiler, but the computer freeze each time I done it. Seems the CPU really occupied by Firefox fully..
It always end up with BSOD, normally profilling on Reddit that's heavier not resulting in BSOD

Actual results:

Slow loading, and CPU Spike about 75% of CPU

Expected results:

It should load fast as normal website

Comment 1

[Benyamin Limanto]

https://share.firefox.dev/3izb86C

After 93 nightly I can open the browser with profiler, this is really make me confused, but it still slow, takes 30s to interact with the website, while on CrEdge, 5s page already rendered with same machine.

on 91 stable no luck with profiling, BSOD will always happen

Comment 2

[Benyamin Limanto]

https://share.firefox.dev/3AG3RYI This's on Dual Core i7-2640m with 16gb RAM and it takes 60s to paint the pages.
For clean profile it need about 50s to fully interact or render the pages proven by https://share.firefox.dev/3xIkn8I (without addons)

Any help is really appreciated as on chrome/CrEdge only took 4-8s to fully load and show the pages, seems firefox struggle to render
ScriptCompileMainThread - <script src="https://cdn.discourse-prod.itsre-apps.mozit.cloud/brotli_asset/application-c68fc6b4cc5d9f6d676a6d629cb33164b7ffb3f81a3e31452d3db1ad5bc0f428.js">

I seen it both on i7-2640m and i7-2670qm. On chrome/CrEdge it will render less than 4s for those CPU. Thank you

Comment 3

[Julien Wajsberg [:julienw]]

From the profile, it looks like we spend a lot of time in JS code. We looked on our beefy computers and we can definitely see a ~500ms grey screen on Firefox that we don't see in Chrome, so I took another profile on my computer: https://share.firefox.dev/2Zond7t.

In the reporter's profile a lot of samples were missing too, so with this new profile we might have a better view.

I'm not 100% sure but it looks like we spend a lot of time "evaluating" something, but it's difficult to say what exactly.

Hope this helps..

Comment 4

[Matthew Gaudet (he/him) [:mgaudet]]

So, Discourse runs a lot of JS -- which doesn't necessarily imply this is a JS engine issue.

The thing that stood out for us most on our triage of this bug is that the Profiler seems to have struggled to capture samples, as there are huge gaps in the profiles provided. This could indicate that something else is consuming resources which is causing Firefox to starve during this period of time.

Another weird thing: the Profiler shouldn't trigger a BSOD; that would be a separate bug if it had continued.

It's not clear we've got enough information to make any progress here; something definitely seems peculiar about the reporter's setup.

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

(See above for Severity change)

Comment 6

[Benyamin Limanto]

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #4)

So, Discourse runs a lot of JS -- which doesn't necessarily imply this is a JS engine issue.

The thing that stood out for us most on our triage of this bug is that the Profiler seems to have struggled to capture samples, as there are huge gaps in the profiles provided. This could indicate that something else is consuming resources which is causing Firefox to starve during this period of time.

Another weird thing: the Profiler shouldn't trigger a BSOD; that would be a separate bug if it had continued.

It's not clear we've got enough information to make any progress here; something definitely seems peculiar about the reporter's setup.

I know. but this doesn't happen on Chromium based browser, I can't tell on safari, but I ask my friend with MacOS and it's also working flawlessly there. This should be a concern, because more and more in the future, web will be move towards JS on client side, and based on my experience with firefox, It's always painful to deal with any JS heavy site on Firefox. Last time I see performance bost only on https://hacks.mozilla.org/2020/11/warp-improved-js-performance-in-firefox-83/ and it's last year, there're nothing new and it's really painful day by day browsing discourse on firefox, I need to fireup CrBased browser for that. I hope there're some ways to lessen up this problem. Thank you

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 8

[boiert]

I believe this bug should be filed at the maintainer of discourse.mozilla.org

After inspecting the profiles and running one of my own I discovered a lot of time is being spent in the deployed application sources, .js assets. and this brings me to a more moral point. Mozilla should, and should stay at, implementing a generic-good platform.

The application sources contain compiled code that has V8-specific optimizations, (or, no optimized references to SpiderMonkey implementations of that same functionality) the only way to 'get faster' at this (without changing the website code) would be to 'just embrace' the V8 engine wholly.
Right now the engine is executing, in 'software'/javascript, an implementation of native functionality.
Akin to using a poly-fill when the user-agent has implemented the required function.

(Think along the lines of: Compiling Node.js to wasm and using that to execute your page's code). The only quick browser would be the one that has already implemented Node.js(V8). That would be ridiculous and common practice at the same time!