[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


Balazs Kelemen <kbalazs at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kbalazs at webkit.org




--- Comment #11 from Balazs Kelemen <kbalazs at webkit.org>  2011-06-29 06:57:42 PST ---
(In reply to comment #10)
> > One thing is decrease CPU load on the main thread. On the other side we can save the time that preloadscanner spends on the main thread. Ideally only the resourcerequest will coast on main thread. Does it make sense and is it possible to modify resource downloading to support download from worker threads?
> 
> So if tokenization time on the cpu is the main target here, it seems like reusing tokens would be strictly superior (as it would work for single core as well as multicore devices). It doesn't seem like too much work to hack up for comparison. Or perhaps I'm missing another benefit of threading here?

Let's look at the html5-parser benchmark results again:
with PreloadScanner: 1774 ms (+/-5.8%)
without PreloadScanner: 23.7 ms (+/-0.55%)
with my ThreadedPreloadScanner: 77.15 ms (+/-1.5%)

>From these number it seems like preloading is even slower than the real parsing. According to this result I guess that the most time consuming part of the preload is not the tokenization but starting the requests. Do you think it is possible? Do you think it can be true on all platforms (with different networking stacks)?  If starting the request is really that costly it would be great to support starting them from a worker thread and make the preload scanner run on a worker thread.

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