Re: [webkit-dev] Parallel CSS styling

2011-06-08 Thread Eric Seidel
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

Re: [webkit-dev] Parallel CSS styling

2011-06-08 Thread Eric Seidel
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

Re: [webkit-dev] Parallel CSS styling

2011-06-07 Thread Roland Steiner
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: [webkit-dev] Parallel CSS styling

2011-06-07 Thread Ojan Vafai
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

Re: [webkit-dev] Parallel CSS styling

2011-06-07 Thread David Hyatt
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

Re: [webkit-dev] Parallel CSS styling

2011-06-07 Thread Eric Seidel
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

Re: [webkit-dev] Parallel CSS styling

2011-06-07 Thread 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

Re: [webkit-dev] Parallel CSS styling

2011-06-07 Thread Kulanthaivel Palanichamy
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

Re: [webkit-dev] Parallel CSS styling

2011-06-06 Thread Eric Seidel
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

Re: [webkit-dev] Parallel CSS styling

2011-06-06 Thread Simon Fraser
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

[webkit-dev] Parallel CSS styling

2011-06-06 Thread Kulanthaivel Palanichamy
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