[webkit-qt] [RFC] Analysis on loading speed

[Lars Knoll]

On Monday 14 December 2009 03:25:11 am ext Holger Hans Peter Freyther wrote:
> Hi All,
> 
> during the last couple of weeks (on an off) I tried to understand the
>  loading behavior of a specific website. In this case it was the english
>  article about the Maxwell Equations on Wikipedia.
> 
> We have two/three things playing together that make our loading speed
> bad compared to other WebKit ports. The first thing is our HTTP network
> stack. It is running in the GUI thread, on top of that the current API
>  forces to start the job only once we are back to the event loop. The next
>  bit is that we are spending a huge amount of time (1 second) on doing the
>  layout (harfbuzz, fontconfig) on this site and the last is that with the
>  Qt Event dispatcher more events are dispatched through one run through the
>  eventloop than with the glib one.
> 
> With the above let me explain what happens. Once we have downloaded
> the CSS/JS WebCore will start to do the layout. We will block in layout
> for the given second. During this time we block we will not send out any
> HTTP requests, not finish/read anything...
> 
> The reason we block longer than other ports is that in Qt we always go
> through the "complex" layout path and the way we use FontConfig is nice
> for a general purpose GUI toolkit but might be overkill for a browser.
> 
> 
> The options I see are the following:
> 
> 1.) Move HTTP to a thread... I had a hacky implementation to move the
> QNetworkAccessManager to a different thread but the QueuedConnection
> implementation acorss threads seems to be not that fast. I have the
> impression that the other thread waits until it is waking up anyway
> (timeout on the select)

We need to do something here in any case. We will always have cases where 
layout takes some time (whether we manage to speed up point (2) below or not). 
We have to be able to immediately send out the HTTP requests.

The current situation is bad, as we wait until we're back in the event loop 
before starting the request. This might cause a DNS lookup that will give us 
one more round through the event loop. Worst case we loose a few seconds with 
this.

> 2.) Make harfbuzz and fontconfig fly. Specially in regard to harfbuzz it
> seems unlikely that we can easily fix it.. in any case it is quite some
>  work on a component not understood by many.

We should look at it again, maybe there's a regression/bug somewhere in font 
loading or harfbuzz. 

But apart from that it'll be hard to speed this up significantly. I've spend a 
significant amount of time three years back optimising harfbuzz as much as 
possible. 

We could try disabling OpenType shaping and kerning for latin fonts, but we 
will then run the risk that we hide issues occurring with non latin writing 
systems (as we don't usually test these). In addition, it'll reduce the 
quality of text layouting.

> 3.) Implement Glyph API in Qt, or disable kerning (as Lars thinks is
>  possible) ...

Disabling kerning is easy. See QFont::setKerning(). In addition, you could try 
disabling font merging (QFont::setStyleStrategy(QFont::NoFontMerging)). How 
much does that make a difference?

Implementing the Glyph API is some more work, and I think Simon and myself 
once decided that the benefits are probably small. IIRC the Glyph API only 
works for Latin and without kerning. That code path should be pretty well 
optimised in Qt already (if we're not hitting opentype).

> 4.) What options do you guys see?

I think we should try to start by fixing the networking stack. Other options I 
was wondering about is whether we can move image decoding into a thread as 
well, so that we don't block our main parser.

Cheers,
Lars

> 
> 
> ideas greatly appreciated.
> 
>        z
> 
> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>