[webkit-dev] Parallel CSS styling

Tue Jun 7 15:54:26 PDT 2011

I'm not convinced focusing on single-threaded performance is the best
approach. Of course, I support any work done to improve it. Antti's work the
past few months has been awesome and I expect there is room for other
improvements.

However, many of the performance improvements we can make to the
single-threaded approach are limited in scope or have other trade-offs. For
example, if I understand https://bugs.webkit.org/show_bug.cgi?id=49876
 correctly, it only applies during parsing and uses 16 more bytes per
RuleData. On some sites (e.g. gmail) that have >30k RuleDatas, that's a
~500k memory hit without much performance benefit. It's a great change for
some sites, but it's a significant cost for others.

On the other hand, http://trac.webkit.org/changeset/78183 is a strict
performance win. It operates by simplifying common codepaths as much as
possible to reduce branching.

I would be excited if we try to simplify the selector matching code and
parallelize it, but, I'm with Eric that we should verify that it's actually
on the critical path first.

Ojan

On Tue, Jun 7, 2011 at 12:16 PM, David Hyatt <hyatt at apple.com> wrote:

> I'll just re-iterate what Simon was saying.  We're very interested in
> improving CSS performance where it's needed, but I would definitely make
> sure non-parallel optimization options have been exhausted first.  I think
> there are still some very big gains to be made selector matching even before
> trying to parallelize it.
>
> I'm not necessarily opposed to parallelization, but I believe it's pretty
> difficult to implement correctly.  It's pretty easy to produce a naive
> parallelization that will look like it works but have correctness and
> stability bugs.  I'm not saying that's what you did, but there are some real
> subtleties with parallelization that you might not be taking into account.
>
> dave
> (hyatt at apple.com)
>
> On Jun 7, 2011, at 1:54 PM, Eric Seidel wrote:
>
> > 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
> >>>>
> >>>
> >>
> >>
> >>
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110607/4bfa5ec4/attachment.html>