[webkit-dev] Parallel CSS styling

[Simon Fraser]

You should start by filing a bug at bugs.webkit.org on that 66%. There may be other easier optimizations that don't have all the complexity of threading.

Simon

On Jun 7, 2011, at 11:22 AM, Kulanthaivel Palanichamy 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