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

UNCONFIRMED
Assigned to

Status

()

P2
normal
UNCONFIRMED
a year ago
a year ago

People

(Reporter: smaug, Assigned: valentin, NeedInfo)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-next])

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.
I've been testing the new UI of youtube.com
youtube.com/new
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.
(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)
Whiteboard: [necko-next]
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.
Flags: needinfo?(jduell.mcbugs)
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.
Flags: needinfo?(jduell.mcbugs) → needinfo?(valentin.gosu)
Assignee: nobody → valentin.gosu
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.
You need to log in before you can comment on or make changes to this bug.