1914340 - Generating dependency graphs on b.m.o is slower in Nightly (and Nightly appears to spend 300ms+ in frontend)

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, task)

Description

[Mayank Bansal]

Go to https://bugzilla.mozilla.org/showdependencygraph.cgi?id=1759123 . For good measure do a hard reload (ctrl+shift +R) on that page and then remeasure.

Nightly: https://share.firefox.dev/4dOv3YS
Chrome: https://share.firefox.dev/3yPPTbG

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Tooru Fujisawa [:arai]]

Can you provide more details about "300ms+ in frontend" part?
I don't see that in the profile.

Comment 3

[Mayank Bansal]

https://share.firefox.dev/3XaZfYO
Its in the taskcontroller #0 and taskcontroller #1

Comment 4

[Tooru Fujisawa [:arai]]

have you modified any prefs, especially dom.script_loader.delazification.strategy ?

The thread shows DelazifyTask, which shouldn't be used by default.
Perhaps some experiment is ongoing?
:nbp, do you know anything about experiment?

Comment 5

[Mayank Bansal]

(In reply to Tooru Fujisawa [:arai] from comment #4)

have you modified any prefs, especially dom.script_loader.delazification.strategy ?

The thread shows DelazifyTask, which shouldn't be used by default.
Perhaps some experiment is ongoing?

I did have dom.script_loader.delazification.strategy =2 set manually.

With that pref set to default, here is a new profile:
https://share.firefox.dev/3YSwX6A / https://share.firefox.dev/4g930Wj / https://share.firefox.dev/3MdB7OS
which shows 200ms in frontend.

Comment 6

[Mayank Bansal]

Strategy 0 : https://share.firefox.dev/3SYHycw
Strategy 1: https://share.firefox.dev/3SYHPfy
Strategy 2: https://share.firefox.dev/3SV6CkD
Strategy 3: https://share.firefox.dev/4ebSnQL
Strategy 255: https://share.firefox.dev/3WYME9A

Comment 7

[Nicolas B. Pierron [:nbp]]

Looking for main-thread frames with frontend:: highlights the different modes of executions, with 49 frames for on-demand delazification, 119 (?) for the checking-with-on-demand testing mode, 39 for both depth-first and large-first off-thread modes, and 12 for the eager-parsing.

Overall, these sounds like good results for the eager delazification, despite taking a lot more time to enter and leave the parser and storing copies of the parsed content …

Are the 300ms+ are referring to the task controller threads?

Comment 8

[Mayank Bansal]

(In reply to Nicolas B. Pierron [:nbp] from comment #7)

Are the 300ms+ are referring to the task controller threads?

Yes

Given the rest of your comment, is there any value in keeping this bug open?

Comment 9

[Nicolas B. Pierron [:nbp]]

Today, there is no value into keeping this bug open, thus I will close it.
However, I do expect some of these to become useful when we would be looking at reducing the cost of copying CompilationStencil, as this is the main cost of off-thread delazification today.