1525256 - Discourse performance issues

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Artem Kondratev [:konart]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

1. Open a web site of your choice
2. Open dev tools (any of the tabs)
3. Try switching between the tabs\pick an element from the page etc.

Actual results:

It takes at least 2-3 seconds for the dev tools to load completely.

During this time - you can interact with page elements (for example you can't put a cursor into the input field) as if you where experiencing some sort of freeze.

After dev tools are finally loaded - switching between tabs also can take a few seconds.

Some profiling on what's going on - https://perfht.ml/2TvFPdW

Comment 1

[Vicky Chin [:vchin]]

Florian, any thoughts on this?

Comment 2

[Florian Quèze [:florian]]

(In reply to konapt from comment #0)

Some profiling on what's going on - https://perfht.ml/2TvFPdW

Alex, anything actionable or unusual in this profile?

Comment 3

[:Harald Kirschner :digitarald]

This is source loading and mapping, done by devtools to get the scripts (onNewSourceEvent/<): http://bit.ly/2U0wOOk

This would presumably affect a script heavy website that is profiled in this case, but I have not seen massive hangs like that elsewhere.

A lot of this changed in 67. Konapt, does this reproduce in Nighty, DevEdition or Beta?

Comment 4

[Artem Kondratev [:konart]]

Can confirm that I see no such problem on the current Nightly or DevEdition. Can't test it on Beta atm, but I suspect it's not there too.

Comment 5

[Alexandre Poirot [:ochameau]]

(In reply to :Harald Kirschner :digitarald from comment #3)

This is source loading and mapping, done by devtools to get the scripts (onNewSourceEvent/<): http://bit.ly/2U0wOOk

+1
It highlights onNewSourceEvent which calls DebuggerSource_getSourceMapURL.
Now, I would like to confirm which particular changeset fix that issue in order to ensure we are correctly tracking this on DAMP.
The only changeset that comes to my mind is bug 1269919, where I prevented calling SourceActor.form twice, thus calling Debugger.Source.sourceMapURL getter two times less.
But I'm not sure it would explain such difference? It would make it twice as fast but not switch from unusable to fast.

Jason, do you have any changeset in mind?
One other modification which would have had an impact here is something on TabSource.source. Something that would make it so that it emits significantly less newSource events. (I saw various changes on this method recently) Or, something in Debugger API, where Source.sourceMapURL getter would have been optimized?

Comment 6

[Jason Laster [:jlast]]

I've seen this performance issue as well. My guess is that it is caused by really large sourcemap base64 data urls.

I saw this last here (bug 1521540). At that time, I prevented including the source actor for each frame. This does not help us when it comes to an initial onNewSource though.

Comment 7

[Alexandre Poirot [:ochameau]]

Konapt, would you mind sharing a reproducable Steps to reproduce this slowness? I imagine mentioning one particular website making the Devtools slow to load could be enough.

Given Jason's feedback, it is most likely related to bug 1521540, which landed in Firefox 66 and seems to be related to one particular usecase: sourcemap served as data URL. So it shouldn't impact all websites but only a few.

Also, bug 1521540 did not trigerred any major improvement on DAMP so we are most likely missing something in DAMP test page and/or script.

Comment 8

[Artem Kondratev [:konart]]

Reproducable as in using Firefox 66 and the same website as in the initial description (https://discourse.mozilla.org/t/devtools-slow-and-occasionally-unresponsive-on-some-sites/19936/2) ?

If yes - than there were no 'steps' really.

1. Open the link metioned above
2. Open Devtools (etry point can be anything, let's say - Inspector)
3. Switch from the initial tab to any other (Debugger, Style Editor)

If no - I can try to reproduce it later today.

Comment 9

[Jason Laster [:jlast]]

Konart, Honza would you mind testing this again?

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I tested STRs from comment #8 (Firefox Nightly) and it works for me just fine (not freezing)

Artem, can you please verify on your end?
Perhaps we can close this one.

Honza

Comment 11

[Artem Kondratev [:konart]]

Sorry for being so late.

As I've said eirlier - https://bugzilla.mozilla.org/show_bug.cgi?id=1525256#c4 - everything seems fine ever since 67 beta. Can't reproduce it on any of the current builds either, so yeah, I guess this one can be closed.