[webkit-dev] Parallel CSS styling

[Eric Seidel]

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
>>>
>>
>
>
>