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 >> <kulanthai...@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@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev