[webkit-dev] Parallel CSS styling

[Kulanthaivel Palanichamy]

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