Closed Bug 1367664 Opened 7 years ago Closed 7 years ago

[Input Latency] Firefox is 100% (100 ms) slower than Chrome in case GMail - Compose new email using keyboard

Categories

(Core :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: wachen, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [QRC][QRC_Analyzed])

User Story

STR:
0. Enable Keyboard Shortcuts in Settings
1. Open GMail
2. Press "c"
3. Wait for the new mail window to open

Short Gecko Profile(cover only Input Lantency action):
https://perfht.ml/2qNdvof

Reports: https://tinyurl.com/knp6swp
Notes: https://docs.google.com/spreadsheets/d/1MsTK1FW88wuLd25A18HG2KqpjYJnvrxGM9a6MeZp35w/edit#gid=256706414

Firefox Profile and Chrome Tracing will be attached in the following.
STR:
0. Enable Keyboard Shortcuts in Settings
1. Open GMail
2. Press "c"
3. Wait for the new mail window to open

Reports: https://tinyurl.com/knp6swp
Notes: https://docs.google.com/spreadsheets/d/1MsTK1FW88wuLd25A18HG2KqpjYJnvrxGM9a6MeZp35w/edit#gid=256706414

Firefox Profile and Chrome Tracing will be attached in the following.
User Story: (updated)
No longer depends on: 1367359, 1367658, 1367660
Blocks: 1367665
No longer blocks: 1367665
Whiteboard: [qf] → [qf][QRC_NeedAnalysis]
Whiteboard: [qf][QRC_NeedAnalysis] → [QRC][QRC_NeedAnalysis]
User Story: (updated)
Short Gecko Profile(cover only Input Lantency action):
https://perfht.ml/2qNdvof
Summary: [Input Latency] GMail - Compose new email using keyboard → [Input Latency] Firefox is 100% (100 ms) slower than Chrome in case GMail - Compose new email using keyboard
(In reply to myen from comment #2)
> Short Gecko Profile(cover only Input Lantency action):
> https://perfht.ml/2qNdvof

In this part of the profile after the key event is handled in the content process:
https://perf-html.io/public/07f6e6a057f7328212062d8a199193d0d16fed8f/calltree/?implementation=cpp&range=1.3871_2.3175&search=Flush&thread=5

We can see 2 expensive operations:
mozilla::dom::CSS2PropertiesBinding::get_direction() triggers a restyle of 42 ms.
mozilla::dom::ElementBinding::get_clientWidth() triggers a reflow of 42 ms.
Andrea, could you help to profile this bug?
Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)
(In reply to Cervantes Yu [:cyu] [:cervantes] from comment #3)
> (In reply to myen from comment #2)
> > Short Gecko Profile(cover only Input Lantency action):
> > https://perfht.ml/2qNdvof
> 
> In this part of the profile after the key event is handled in the content
> process:
> https://perf-html.io/public/07f6e6a057f7328212062d8a199193d0d16fed8f/
> calltree/?implementation=cpp&range=1.3871_2.3175&search=Flush&thread=5
> 
> We can see 2 expensive operations:
> mozilla::dom::CSS2PropertiesBinding::get_direction() triggers a restyle of 42 ms.
> mozilla::dom::ElementBinding::get_clientWidth() triggers a reflow of 42 ms.

A bunch sync restyle/reflows, maybe Daniel can also take a look.
Flags: needinfo?(dholbert)
(In reply to Cervantes Yu [:cyu] [:cervantes] from comment #3)
> We can see 2 expensive operations:
> mozilla::dom::CSS2PropertiesBinding::get_direction() triggers a restyle of 42 ms.
> mozilla::dom::ElementBinding::get_clientWidth() triggers a reflow of 42 ms.

Minor correction: the latter 42ms for get_clientWidth is mostly not reflow (though it is prompted by a layout flush).

It's really a 26ms restyle (ProcessPendingRestyles, which in this case is mostly nsCSSFrameConstructor), and then there's 15ms of reflow (ProcessReflowCommands).
Daniel, Do you think there is a bug that needs to surface from this? If not I can close this bug.
Assignee: amarchesini → nobody
Sorry for the delay here.

(In reply to Jean Gong from comment #7)
> Daniel, Do you think there is a bug that needs to surface from this?

I don't think so -- not a layout/restyle one, at least.

The 15ms reflow inside of get_clientWidth seems to be for extremely-deeply-nested block reflow.

The one thing that stood out to me there is that we're spending 3 samples (3ms of that 15ms reflow) inside of nsNativeThemeWin::GetWidgetBorder:
https://perfht.ml/2uNeWcF

Fortunately, that code has been optimized recently, to cache results inside of that function! That happened in bug 1373079. So I expect this has improved a bit (shaving off a few ms) as a result of that bug.

Beyond that, nothing about the reflow jumps out at me as obviously expensive or optimizable -- and for the restyles, we can hope that stylo will help there.

> If not I can close this bug.

That makes sense to me, I think.
Depends on: 1373079
Flags: needinfo?(dholbert)
Er sorry, I meant to say 4 samples (4ms of that 15ms reflow).  (The profiler shows 3ms with one inverted callstack, and 1ms with a different inverted callstack - but they're all inside of that same reflow [same call to ProcessReflowCommands].)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Whiteboard: [QRC][QRC_NeedAnalysis] → [QRC][QRC_Analyzed]
Flags: needinfo?(amarchesini)
You need to log in before you can comment on or make changes to this bug.