Investigate a better heuristic for when to prewarm a process

• Component: WebKit2
• Status: NEW ---

[Saam Barati]

Some ideas:
- on the 'load' event
- a timer X ms after the 'load' event.

Or some combination of a timer an load event or first paint.

Perhaps there are other heuristics as well

[Saam Barati]

one way the current heuristic falls down is:
- load "a.com" <-- does prewarm a process
- press a link on "a.com" going to "b.com" <-- uses the prewarmed process
- Go back (to "a.com" <--- does not prewarm a process
- press a link on "a.com" for "c.com" <-- does not use a prewarmed process because one doesn't exist

So we should take into account prewarming a process when using back/forward cache

[Saam Barati]

(In reply to Saam Barati from comment #1)
> one way the current heuristic falls down is:
> - load "a.com" <-- does prewarm a process
> - press a link on "a.com" going to "b.com" <-- uses the prewarmed process
> - Go back (to "a.com" <--- does not prewarm a process
> - press a link on "a.com" for "c.com" <-- does not use a prewarmed process
> because one doesn't exist
> 
> So we should take into account prewarming a process when using back/forward
> cache

actually, I'm off here. Maybe we don't need to do anything, since we do end up using a prewarmed process for "c.com", because "b.com" will prewarm a process

[Radar WebKit Bug Importer]

<rdar://problem/40094910>

[Geoffrey Garen]

I think we also need to merge navigation process prewarming with the process prewarming we already do to speed up launch.

[Saam Barati]

(In reply to Geoffrey Garen from comment #4)
> I think we also need to merge navigation process prewarming with the process
> prewarming we already do to speed up launch.

Merge in what sense? They both call the same codepath if that’s what you mean

[Geoffrey Garen]

> Merge in what sense? They both call the same codepath if that’s what you mean

Yeah, I guess that's what I mean. :P