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