[webkit-dev] Parallel CSS styling

[David Hyatt]

I'll just re-iterate what Simon was saying.  We're very interested in improving CSS performance where it's needed, but I would definitely make sure non-parallel optimization options have been exhausted first.  I think there are still some very big gains to be made selector matching even before trying to parallelize it.

I'm not necessarily opposed to parallelization, but I believe it's pretty difficult to implement correctly.  It's pretty easy to produce a naive parallelization that will look like it works but have correctness and stability bugs.  I'm not saying that's what you did, but there are some real subtleties with parallelization that you might not be taking into account.

dave
(hyatt at apple.com)

On Jun 7, 2011, at 1:54 PM, Eric Seidel wrote:

> You noted it spends 66% of its "CSS time" in StyleForElement.  What
> about total page load time?
> 
> Then again 6450ms spent in CSS sounds like a lot of time regardless.
> Answering what % of total page load time we're spending in CSS (or
> StyleForElement) is important.
> 
> Loading www.flickr.com/photos/tags/sanfrancisco on my 4-core 2.66ghz
> Mac Pro doesn't take anywhere near 6 (or for that mater 9!) seconds,
> so I'm confused how you got 9s in CSS code on a (supposedly faster)
> machine loading that flickr page.
> 
> I'm building WebCore so I can shark the page now.
> 
> Thanks again for your investigation efforts.
> 
> -eric
> 
> On Tue, Jun 7, 2011 at 11:22 AM, Kulanthaivel Palanichamy
> <kulanthaivel at codeaurora.org> wrote:
>> Eric,
>> 
>> You're right that in flickr.com main page, Webkit spends very little time
>> in StyleForElement. However, if you visit
>> http://www.flickr.com/photos/tags/sanfrancisco/ , WebKit spends most of
>> its CSS time in StyleForElement. For example, in our test machine (an
>> 8-core Intel Xeon, 2.8GHz) StyleForElement takes 6450ms out of  9748 ms
>> spent on CSS (66%). Our algorithm focuses on that 66%, and makes it scale
>> linearly. The version of Webkit that we tested includes this patch: Bug
>> 49876 - Optimize matching of descendant selectors
>> 
>> Other websites that would benefit:
>> •       amazon (68% in SFE)
>> •       Google search (57%)
>> •       Yahoo sports (56%)
>> •       Apple (58%)
>> •       Wikipedia article (65%)
>> 
>> -Kulanthaivel
>> 
>>> Do you have statistics on how much total time rendering flickr.com is
>>> in CSS/Style code at all?  I believe it to be very low.
>>> 
>>> -eric
>>> 
>>> On Mon, Jun 6, 2011 at 1:16 PM, Kulanthaivel Palanichamy
>>> <kulanthaivel at codeaurora.org> wrote:
>>>> Hi All,
>>>> 
>>>> At Qualcomm Innovation Center we have been working on a parallel
>>>> algorithm
>>>> for CSS styling and wanted to see if there is any interest in the
>>>> community to see it implemented in WebKit. The overall idea is that we
>>>> replace CSS matching and styling with a parallel implementation assuming
>>>> there is a barrier before and after the computation. CSS style
>>>> application
>>>> will be performed by the main thread, such that we avoid the need to
>>>> make
>>>> thread safe data structures accessed in other passes. The algorithm is
>>>> task-based, so we would need to implement a thread pool and a simple
>>>> task
>>>> scheduler (or maybe use an existing one).
>>>> 
>>>> In particular, our algorithm requires modifying Element::recalcStyle()
>>>> and
>>>> some of the methods it invokes. Code that calls Element::recalcStyle()
>>>> will not have to be changed. By the time Element::recalStyle() returns,
>>>> all threads involved on the parallel CSS styling have completed their
>>>> execution.  Effectively, there is a barrier when Element::recalcStyle()
>>>> begins and another before it returns.
>>>> 
>>>> Our experiments show that our CSS computation for complex websites
>>>> scales
>>>> rather well. For example, we observed that, for  flickr.com, Webkit
>>>> spends
>>>> 75% of its time in CSS doing CSS matching. Thus, our algorithm would
>>>> give
>>>> a maximum speedup of 1.6X on 2 cores and 2.3X on 4 cores.
>>>> 
>>>> Please let us know whether this would be of interest to the community.
>>>> 
>>>> 
>>>> -Kulanthaivel
>>>> 
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>> 
>>> 
>> 
>> 
>> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev