1374434 - Investigate if Necko could send data sooner to mainthread/parser thread while loading youtube.com

Status: RESOLVED INACTIVE

(Core :: Networking, enhancement, P2)

Description

[Olli Pettay [:smaug][[e-mail]]]

While investigating youtube first paint timing, most of the time after
navigation start main thread is waiting for parser to send data to it, and parser seems to be waiting for data from Necko.
I don't know if Necko just doesn't get the data sooner, or if there is something to optimize.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

I've been testing the new UI of youtube.com
youtube.com/new

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Do we start url loading in parent process when user types the url to location bar and presses enter?
Since that is the testcase here, open new tab, type url, press enter.

Comment 3

[Dragana Damjanovic [:dragana]]

(In reply to Olli Pettay [:smaug] from comment #2)
> Do we start url loading in parent process when user types the url to
> location bar and presses enter?
> Since that is the testcase here, open new tab, type url, press enter.

There is not much delay here. The request goes from child to parent as soon as the channel is opened. The olny thing that can delay connecting to the server is tracking protection(I do not know if tracking protection will delay anything here)

we could do a bit of testing to see if we can optimize something.

There is bug 1348275 that sounds relevant here.

(Predictor could sometime speculatively connect to a server even earlier, but that depends on how often a site is visited)

Comment 4

[Dragana Damjanovic [:dragana]]

Jason, does anyone has time to take a look? I am not sure if we can really optimize anything here, maybe location bar can speculatively connect to a server on click.

Comment 5

[Jason Duell]

Valentin: can you poke around at this a little?  It seems we have two things to look at here:

1) Profile youtube/new and see if necko is indeed the problem.  It's not clear to me from what we've got here that IPC, etc is the problem, or if the server is slow, or what.

2) We have the interesting idea that we might be waiting until the child is notified of navigation before launching necko channels, and that we could skip an IPC latency via the awesomebar or some call into the predictor.

#1 is more important.

If #2 doesn't turn out to be the cause of #1, I'd say split it out into it own bug at some point.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

FWIW, Bug 1383299 is sort of a variant of this, though only about initiating the connection.
So basically (2).
I wonder if there are still ways to optimize how soon parser thread in child process gets the data.

Comment 7

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 8

[Selena Deckelmann :selenamarie :selena]

Olli - is this issue still worth investigating?

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

I guess we can close this now. Lots of other page load profiling and optimization happening and we'll open new bugs when needed.