[Webkit-unassigned] [Bug 63531] Turn PreloadScanner implementation to a thread based solution

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=63531





--- Comment #37 from Balazs Kelemen <kbalazs at webkit.org>  2011-08-08 02:34:47 PST ---
(In reply to comment #36)
> It is unlikely that threading something that takes very little CPU time is going to make page loading faster, especially since the actually triggering of the loads still has to happen in the webkit thread. We definitely are not going to accept a patch that introduces more threading (and all the associated complexity) without showing useful performance gains. Your efforts would probably be better spent elsewhere.

Your arguments are reasonable but I still did not give it up :)
Yes, it seems like load time of typical web pages won't be really faster.
However, doing the scan in parallel has the following advantages:
 * It eliminates the worst case which is blocking in the preload scanner when the resource that we are waiting for has already arrived. This is the case with the html-parser benchmark and that's why the patch speeds it up. Actually this is the case with every page that refers to some script or css at the beginning and has a lot of text.
 * It helps in kicking off the load a bit earlier because we can give each chunk to the scanner as soon as it has arrived. Unfortunately this benefit cannot be shown by page load time tests.

I can support the first point with the current numbers (with a newer local version of the patch).

html-parser
Ref
    avg 1786.85
    median 1781
    stdev 25.16997218909866
    min 1758
    max 1844
Parallel
    avg 1015.85
    median 1013
    stdev 6.174746958378132
    min 1010
    max 1026

Methanol with some popular site
ref      1157.39
parallel 1145.5

Methanol with some popular site + PerformanceTests/Parser/resources/html5.html
ref      40070
parallel 36824

The sites I used with Methanol were the local copies of http://www.blogger.com/, http://www.conduit.com/, http://www.facebook.com/, http://www.qq.com/, http://twitter.com/, http://www.google.com/, http://www.microsoft.com/, http://www.ebay.com/ and http://www.wikipedia.org/.

My further plan is to do a web-page-replay based benchmark on Mac that would show the behaviour with (simulated) network latency.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.