Like for the other parts of Qt, having great performance is important for QtWebKit.
Traditionally, QtWebKit has been mostly used on desktop computers for advanced layouting, hybrid applications or simply to browse the web. On a modern computer, the speed of WebKit is not a problem.
The world has changed, and QtWebKit is now used on mobile phones running Maemo, Symbian or Windows CE, and it is more and more used in embedded application on various devices.
Working on what matters
To improve the performance of WebKit, we works with benchmarks. Those benchmarks are used as use cases when profiling WebKit and to evaluate the gain of our patches.
Those benchmarks and the tools are available on Gitorious, in the QtWebkit performance repository.
WebKit gives a lot of possibilities, and we try to focus our work on what matters. For the performance work, we use real webpages, and look for ways to improve WebKit in the way it is used on the Web.
How we benchmark WebKit
The performance suite has three kinds of tools:
- host tools: to manage the data used by the benchmarks
- tests: the benchmarks
- reductions: some benchmarks for specific components of WebKit
Let’s have a look at the tools and the tests. The full documentation of the performance suite is on the WebKit’s wiki.
Mirroring the web
For the benchmark, we do not want to access Internet directly. We want to compare the results from one run to the other, so we don’t want the pages to change arbitrarily. Using the Web for benchmarking would also create an important load on the servers.
To use real pages without going online, we create databases of web pages with the mirror application:
Those databases are snapshots of webpages at a given point in time, and they are used as input of the benchmarks.
The mirror application uses WebKit to load the pages and intercept all network requests. This means the database also includes resources that are loaded lazily via Javascript.
Using the benchmarks
There are two ways to exploit the databases with the benchmark: the online and offline modes. The difference lies in the way we provide the database’s content to the benchmarks:
In the “online mode“, we use a basic web server to serve the database over HTTP. The benchmarks use the complete stack to load pages, as they would if we were loading the page from Internet.
In the “offline mode“, the database is loaded directly by the benchmarks and is used as the source of data. In that case, the network is not involved. This mode is mostly useful for the benchmarks that do not involve the network (like measuring the rendering speed).
What is measured
The benchmark suite is still a work in progress. Currently, there are benchmarks for:
- the page loading performance (with or without rendering)
- the rendering performance
- the scrolling performance
How you can use that?
If you use WebKit, and are interested in great performance, you can use the performance suite to profile the use case you are interested in, and optimize those cases.
If you evaluate the use of WebKit for embedded, you can use the benchmark to evaluate how good WebKit performs on the hardware.
If you make patches for WebKit’s performance, have a look on how to contribute. You can also join us on IRC in #qtwebkit on freenode.
Possibly related posts:
12 comments
Hi,
The webkit rendering engine is pretty fast, but not the javascript engine that comes with qtwebkit (qtscript ?). It’s, even for desktops, slow, because of lot of javascript code that is present on current sites.
About small devices, I think the big issue is reduce memory used because of qt metaobjects and other things that it’s not always used.
> The webkit rendering engine is pretty fast, but not the javascript engine that comes with qtwebkit (qtscript ?). It’s, even for desktops, slow, because of lot of javascript code that is present on current sites.
The engine of WebKit and QtScript is JavascriptCore. It does a good job but there is not much we can do against slow scripts, especially on embedded.
Some engineers from the university of Szeged try to improve the situation. More infos here: http://webkit.sed.hu/blogs
> About small devices, I think the big issue is reduce memory used because of qt metaobjects and other things that it’s not always used.
I did not mention it but we also work on memory consumption. The use of memusage is documented http://trac.webkit.org/wiki/QtWebKitPerformanceUtilities Holger has already done improvements in this area.
While we’re talking about optimizing QtWebKit, how about optimizing for anther metric that would also greatly benefit mobile devices (and desktop application deployment too): disk space. In its current form, a compiled copy of QtWebKit is quite large. Let’s look at some reason numbers:
-the disk image for my application is 43 mb
-my application bundle (universial, ppc + intel) is 114.4 mb
-my application executable itself is only 12.4mb
Hrmm, so where is all the space going?
-all the frameworks I’m including add up to 89.8 mb. Here are the Qt ones:
QtGui.framework – 22.6 mb
QtCore.framework – 5.4 mb
QtXML.framework – 877 kb
QtXMLPatterns.framework – 13.5 mb
QtSvg.framework – 754 kb
QtNetwork.framework – 2.5 mb
QtWebKit.framework – 41.9 mb
So if you compare hte size of QtWebKit compared to my entire application bundle, before it’s compressed down to a disk image, QtWebKit is taking up 36.6% of my total space. That’s a lot of disk space! When compiled on Windows, where we obviously only need Intel bits, things are considerably smaller, but even more than you’d expect, despite the fact that on both Windows and Mac I’m compiling with GCC.
But back on topic, QtWebKit has grown quite large. Are there any plans to try to slim down the size of the compiled framework/library in the future, or is QtWebKit destined to continue to bloat up as time goes by?
@Will Stokes
How do you suggest we reduce the size?
@Benjamin, for reducing size, it would be nice if Qt supported compiling out features for all the modules on the desktop (like on embedded).
(One option is to link statically with Qt to reduce size, though this approach may not work for all because plugins also have to be statically compiled)
@Benjamin & @girish:
I’m no expert here. In the past I used to compile and link to Qt statically. This did produce a slightly smaller binary, although it also make my application start slower. We opted to switch from commerical to LGPL and now we’re stuck with dynamic, not static linking, so static is not an option for us.
I continue to compile Qt myself. For those who are interested, here are the flags I use currently:
./configure -opensource -silent -prefix $PWD/../qt \
-nomake examples -nomake demos \
-no-phonon -no-phonon-backend -no-audio-backend -no-multimedia \
-no-gtkstyle \
-no-sql-sqlite \
-no-qt3support \
-universal -sdk /Developer/SDKs/MacOSX10.4u.sdk
As you can see I’m disabling phonon and qt3 support since we don’t use either in our application (we might use Phonon down the road, but for now there is no need to include it). The #’s I quoted above did not include the following flags:
-no-audio-backend -no-multimedia -no-gtkstyle -no-sql-sqlite
I’m trying those now and hope to see a small improvement.
Additionally, I’d online somewhere where a while back someone was manually editing the mkspecs for their platform (win32 + mingw but in theory this would also apply to osx + gcc) to use the following flags:
-Os -mpreferred-stack-boundary=2 -finline-small-functions -momit-leaf-frame-pointer
I’m not familiar with these flags. Clearly -Os is optimize for size (right now I believe Qt uses -O2 so it never sacrfices space for speed). I’m not sure how helpful the latter flags here might be, perhaps quite a bit? I have yet to experiment with these. If anyone reading this has I’d love to hear what you think of those flags and if they helped you drop the size of the application any.
Currently if my application crashes I’m able to get at a call stack quite easily. Even if I’m running it outside QtCreator I simply begin the “report to apple” process, then click details or something and view the information, then cancel out. I’m seeing all the function names for both my and Qt’s code. Perhaps QtWebKit could be reduced further by somehow ripping out the debugging symbols in Qt code? Generally speaking, if my app crashes because of a bug in Qt, all I need is the offending line in *my* code to see where the problem occured, not the full call stack within the QtWebKit call stack as well. I’m not sure how much space this debugging information is taking up.
I am considering breaking my disk image in half. I could produce one disk image for PPC folks and another for Intel based Macs. This would theoretically cut my disk image size in half, and also save on bandwidth when users download the application, but it’s not as nice as providing a single download that works on all Macs.
I’m not familiar with the QtWebKit code base at all, so I’m curious for those of you who are, what parts of QtWebkit are taking up so much space? Rather than trying to optimize code randomly, it would be nice to know where the bulk of the C/C++ code is in general.
Hey Benjamin,
I hope you guy’s continue to look into the performance of QtWebKit on the desktop. I’m working on a project utilizing QtWebKit and the slow performance of the application renders it completely unusable on Mac and Linux. Also, while it is faster on Windows, there are still some deal breakers.
The problems I am seeing can be seen here: http://gist.github.com/288082. If you simply load this page in the Qt Demo “Fancy Browser”, you’ll see the issues on the desktop. Also, if you load the same example in Safari, you will see that the performance is stellar.
The main problems are:
* Scroll speed (causes dom manipulation in this example)
* Window resizing
* CSS resizable columns of from “resize: horizontal”
With these problems, this app will not be shippable. I’d love if there was anything that I could do to help you out in making this faster, because I think this has a lot of potential.
Justin
The link I posted doesn’t work because of the period at the end of the sentence. Here is the actual page.
http://gist.github.com/raw/288082/95eb31e911d2a8e531c5d8561a17a62814c05bce/scrolltable.htm
@iamjwc
We continue to work on the desktop’s performance as well. Most improvements are interesting for both desktop and embedded.
About http://gist.github.com/288082. Could you create a bug report on bugzilla (with “Qt” and “Performances” in the keywords), and attach profiles/traces?
I have tried the page with WebKit trunk, and I don’t see any performance issue (especially with the graphics system raster, the frame rate is excellent).
About window resizing and column resizing, most of the time should be spent on layouting, and there is no difference with Safari. Actual data on your computer, like profiles, are valuable to report a problem like this on WebKit’s bugzilla.
@Will Stokes and Girish
If size is an issue and you do not need all the features of WebKit, you can try do disable some. If you look at WebCore.pro in WebKit, some feature are compiled only if enabled (look for ENABLE_ in the file). You might be able to squeeze a few megabytes by disabling some features.
Today I tested the latest code (4.6.2 stable and 4.7 technology preview). Unfortunately the speed is unacceptably slow! Running sunspider on Mac Pro is almost 5x times slower than current WebKit! Where is the problem??? What kind of optimization here is talk about? Maybe I am missing something or doing wrong, but compiling and testing on the same hardware using QT or XCode with native WebKit(10.6.2 MacOSX) is like day versus night. Unless the speeds will come to comparable level, it will sadly refrain us away from using this multiplatform (QT) library..
So the question is: If You are stating that QT uses latest (stable) WebKit then why it’s real world situation is saying the opposite?
Here are the benchmarks:
QT 4.6.2 – 1524 ms
QT 4.7 preview – 1524.8 ms
Safari 4.05 – 405.2 ms
WebKit(6531.21.10, r52686) 2nd jan 2010 build – 320.4 ms
WebKit latest r56669, 27March 2010 build – 339.2 ms
Basic browser built with XCode using 10.6.2 Webkit libs on MacOSX – 388.6 ms !
@Stju
The tech preview of Qt 4.7 still used the old branch of Qt 4.6 for WebKit. The engine could not be updated on time for the release.
Try the last beta of Qt 4.7, this one has the updated version of WebKit.
Comments on this entry are closed.