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
Selector matching performance has been improved considerably via
https://bugs.webkit.org/show_bug.cgi?id=49876 and other bugs. With those
changes,
I would expect that the win from using threading is rather low.
Simon
On Jun 6, 2011, at 1:16 PM, Kulanthaivel Palanichamy wrote:
> Hi All,
>
> At
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
wrote:
> Hi All,
>
> At Qualcomm Innovation Center we have been working on a parallel algorithm
> for CSS s
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) StyleF
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
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
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 t
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
si
On Wed, Jun 8, 2011 at 7:54 AM, Ojan Vafai wrote:
> 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
Re-sending w/o the attached file.
On Wed, Jun 8, 2011 at 3:31 PM, Eric Seidel wrote:
> I used Safari's built-in Page Load Test mechanism to test the page.
>
> I created a flickr.pltsuite and placed it in
> /Applications/Safari.app/Contents/Resources/flickr.pltsuite with the
> contents:
> http://w
If you are interested in optimization suggestions inside WebKit, I'm
happy to have a lengthy discussion with you over #webkit.
We've talked about moving the HTML5 parser off into its own thread,
which may be a win on some pages.
WebCore's memory usage is way too high (which also affects execution
11 matches
Mail list logo
