Open Bug 1349198 Opened 3 years ago Updated 4 months ago

[Performance] Slow action when switching rapidly through tabs in Details panel

Categories

(DevTools :: Netmonitor, defect, P2)

defect

Tracking

(firefox52 unaffected, firefox53 unaffected, firefox54 fix-optional)

Tracking Status
firefox52 --- unaffected
firefox53 --- unaffected
firefox54 --- fix-optional

People

(Reporter: ciprian_georgiu, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: regression, Whiteboard: [netmonitor])

Attachments

(1 file)

[Affected versions]:
- latest Nightly 55.0a1
- latest Aurora 54.0a2

[Affected platforms]:
- Windows 10 x64
- Ubuntu 16.04 x64 LTS
- macOS 10.12

[Steps to reproduce]:
1. Start Firefox. 
2. Go to a website that has many requests e.g.: http://www.bbc.com/ or http://edition.cnn.com/.
3. Open netmonitor. (Ctrl + Shift + Q) and select a request from the list.
4. Switch rapidly through Details panel tabs (Headers, Cookies, Params, Response etc. )

[Expected result]:
- Tabs are switched properly and no delay can be seen.

[Actual result]:
- When switching through tabs there is a bit of delay.

[Regression range]:
- This seems to be a regression in Fx 54 after bug 1317645 landed. I will follow-up with a regression range asap.

[Additional notes]:
- see the attached sceencast
Has STR: --- → yes
Flags: qe-verify+
Priority: -- → P3
Whiteboard: [netmonitor-reserve]
No longer blocks: netmonitor-html
Priority: P3 → P2
Whiteboard: [netmonitor-reserve] → [netmonitor]
Note that the slowest tab might be ResponseTab due to CodeMirror editor embedded with iframe. Bug 1350226 will remove the extra iframe and render CodeMirror directly, which could mitigate open delayed issue a lots.
Summary: Slow action when switching rapidly through tabs in Details panel → [Performance] Slow action when switching rapidly through tabs in Details panel
Assignee: nobody → gasolin
Status: NEW → ASSIGNED
Iteration: --- → 55.3 - Apr 17
Priority: P2 → P1
Iteration: 55.3 - Apr 17 → 55.4 - May 1
Ciprian, we have updated Bug 1350226 and the tab switching looks smoother now. Could you help verify it?
Flags: needinfo?(ciprian.georgiu)
I can see some improvements with latest Nightly 55.0a1 (2017-04-23) on Windows 10 x64 compared to Nightly (2017-03-21) when this bug was reported. The tab switching looks a bit smother now, but there is still a noticeable difference between 53.0 Firefox release - where tabs switching happens instantly, and after the patch landed in Bug 1350226.

On Ubuntu 16.04 x64 and Mac OS X 10.11.6 I cannot see any differences, switching rapidly through tabs is still causing delays and sometimes hangs, as you can see on OS X here: https://goo.gl/mxEB1y. I tested this on http://www.bbc.com/ and I had around 200 requests.

Fred, please let me know if I can help with more info!
Flags: needinfo?(ciprian.georgiu)
Hi Ciprian,

Could you help confirm the slowest case is when switching in response tab or switching from response tab to others? It's hard to tell where is slow in your attachment gif. I can figure out when you start clicking on a tab and how is the latency in between clicking and content showing.
Flags: needinfo?(ciprian.georgiu)
Hi Ricky,

The latency happens when I start switching from Response tab to others.
Flags: needinfo?(ciprian.georgiu)
Thanks your reply!

Another question is that are you testing it by mouse clicking? I can see the latency happens when switching away from ResponseTab by navigating tabs with arrow key, but it looks like a corner case for me. IMO, the normal use case is that mouse click these tabs as faster as possible.

Furthermore, tab switching would be slow down when network requests are still loading in background. We should make sure that all network requests are ready and ceased. I suspect there could be another issue (loading large amount of requests will slow whole netmonitor down) affects to this result.
Flags: needinfo?(ciprian.georgiu)
Yes, I'm testing it by mouse clicking and all requests were loaded in the background. I noticed that the delays are more visible if a html is selected as "Type" request and a js document as "Cause". I have to make a correction from comment 4, Windows 10 is affected as well by this issue.

 (In reply to Ricky Chien [:rickychien] from comment #7)
...
> I suspect there could be another issue (loading large amount of requests will slow whole netmonitor down) affects to this result.

This seems to be right, since as soon as netmonitor reaches 200 requests or more, the performance starts to slow down.
Flags: needinfo?(ciprian.georgiu)
Ah, I didn't noticed there is a video on comment 4. The video shows all issues I want to know. Thanks!

The latency is due to CodeMirror (source editor in response tab) initialization time. It takes a few milliseconds to start up and load source content. In the case when file size < 50kb, it will try to do syntax highlight which also slow down perf.

Possibility Solution (this is also old solution from XUL implementation but I removed after react rewrite)

Create a CodeMirror instance when network details panel is opened, but do not destroy it. Instead, we can move its position out of the screen to let CodeMirror invisible. Or move its position back when response panel or params panel need to show CodeMirror again.
For the top priority perf issue, we will focus on perf issue in request list.
Assignee: gasolin → nobody
Status: ASSIGNED → NEW
Priority: P1 → P2
Iteration: 55.4 - May 1 → ---
Given that the devtools team has triaged this already, marking as fix-optional.
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.