1402962 - switching to and from a particular tab is very slow

Status: NEW

(Core :: Graphics: Text, defect, P3)

Description

[Asa Dotzler [:asa]]

When viewing about:telemetry's Raw JSON in a tab, switching to or from that tab produces a short browser hang as documented in this profile https://perfht.ml/2jYy5Us

Steps to reproduce: 
1. Load about:telemetry
2. click the "Raw JSON" link in the lower left of the screen.
3. switch between the raw JSON tab and the about:telemetry tab a few times.

Result: tab switching hangs for a second or more. 

Expected results: tab switching should always be blazing fast. 

Note: this is not the same as bug 1399265 which is about the performance within the JSON viewer tabs. This bug is about switching between browser tabs being slow.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Are you using the mouse or a keyboard shortcut to switch between tabs?  Just curious because I think our "warm up the tab" improvement only helps with mouse switching.

Comment 2

[Asa Dotzler [:asa]]

mouse switching

Comment 3

[Selena Deckelmann :selenamarie :selena]

Andrew - can you help me find a home for an investigation into this?

Comment 4

[Andrew Overholt [:overholt]]

Looks like long rasterizations. There's also a bunch of time spent in some harfbuzz code. Maybe Jonathan has an idea?

Comment 5

[Jonathan Kew [:jfkthame]]

Hmmm. So it looks to me like one issue -- perhaps the major issue -- here is that we spend a bunch of time (re-)measuring the text of the megabyte-long base64-encoded data: URL that we're putting in the awesomebar when we go to the raw JSON view.

I'm not sure exactly which codepaths are leading us here; I guess we measure it in order for the URL bar to decide whether to apply its text-overflow fade effect, but for all I know we might also be measuring it as part of setting up the URL bar's tooltip, and/or the awesomebar's drop-down menu, both of which would display the URL. And XUL layout tends not to be very optimal (e.g. XUL textboxes don't cache their textruns, they just create them on-demand to measure or draw, and then discard).

Comment 6

[Jonathan Kew [:jfkthame]]

So I guess what I'm wondering is whether we could somehow avoid putting such a huge string into the URL bar when we show the JSON view of the ping?

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

Assuming this is not a recent regression.

Comment 8

[Jonathan Kew [:jfkthame]]

Incidentally, when I tried to reproduce this in my local development build, I don't see the slowness. But that'll be because the JSON data of its telemetry ping is only a fraction of the size of my usual Nightly's one; it ends up at about 36K of base64-encoded data, rather than a megabyte.

I'm a bit taken aback, TBH, at the sheer bulk of this telemetry-ping data. Seems like an awful lot of bits to be pushing up people's connections (unless they've opted out).

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Andrew, who can answer the "why do we need all this in the telemetry ping" question?

Comment 10

[Andrew Overholt [:overholt]]

(In reply to Milan Sreckovic [:milan] from comment #9)
> Andrew, who can answer the "why do we need all this in the telemetry ping"
> question?

Maybe chutten? mystor pointed me to https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/data/main-ping.html

Comment 11

[Chris H-C :chutten]

If pings are too large (1MB, IIRC), we drop them on the floor and don't send them[1]. We compress them in transit using gzip (and on disk using lz4) so the actual payload sizes might be smaller than you think.

But to the question as asked "Why do we need all this in the telemetry ping?"

If you want to know why our data payload format isn't as concise as it could be, that's a history lesson. The future is that the most egregious offenders (flag and count histograms) are gradually being replaced with Scalars which are much smaller (and nicer to work with).

If you want to know the broader context, I'm not _really_ the one you want to be asking the Big Questions about data collection. For that you probably want to talk to a Data Peer (the current list is at [2] and comprises Rebecca Weiss, Chenxia Liu, and François Marier).

As I understand it, each and every piece of information was requested and reviewed for size and suitability according to our Data Collection Policy[2]. Each probe has an expiry date or is reviewed on an annual basis for its continued suitability and relevance.

The information collected was and continues to be deemed necessary, in other words.

[1]: https://mzl.la/2fUgqc4 for pings evicted before we save them to disk, https://mzl.la/2fTzabF for pings evicted before we send them
[2]: https://wiki.mozilla.org/Firefox/Data_Collection