原文:
http://blog.qt.digia.com/blog/2013/04/15/evolution-of-the-qml-engine-part-1/Evolution of the QML engine, part 1<div qt-metadata-icons"="">Published April 15, 2013 | By <a fn="" n"="" href="http://blog.qt.digia.com/blog/author/lars/" title="View all posts by Lars Knoll">Lars Knoll
QML as a technology has become increasinglyimportant for the success of Qt. It allows for the creation of smooth,animated user interfaces, in line with expectations on the market today.There are three main features, that
make it so suitable for UIcreation. The first one is the declarative syntax, that makes itextremely easy to create these user interfaces and have both developersand UI designers work on the same code base. Secondly, the technologymakes the integration of native code relatively easy, allowing to domuch of the application logic and heavy lifting in
C++. And finally, thechoice of Javascript as an integral part of the QML language allows foreasy prototyping and opens the technology up to a wider audience.
The engine as it is today is a fantastic basis and fills most of ourusers needs. However, it also has a couple of shortcomings and problemsthat will need to get solved in the future. This series of blogs isgoing to outline our findings and present the solutions that we areplanning to implement for them. The goal will be to get to a better,more flexible and easier to maintain QML engine in the future.
So let’s start of with some of the problems we’re facing with the current engine.
- Several object models
The current QML engine uses the V8 Javascript engine to execute propertybindings. Each QML item has several representations internally. Onetowards V8 (using the public V8 API), one towards the QML engine, andone to expose it as a QObject to native Qt. The problem here is thatthis requires the QML engine to keep these different representations insync, leading to a lot of glue code and rather high memory consumptionto hold the different representations. - Bindings done through JS closures
Each binding is represented as a JS function closure towards V8. Thisrequires rewriting the expression as a closure, and then letting V8parse the rewritten expression once again. Evaluating the bindingrequires calling a JS function in V8 with quite a bit of overhead toinstantiate the proper context for executing the binding. This is ratherslow and lead to the development of a small expression interpreter(called V4) inside the QML engine that would evaluate simpleexpressions. This interpreter is many times faster then evaluatingthrough V8. - Data type conversions
One reason why evaluation of expressions in V8 is slow is the overheadof converting data types from Qt to V8 and vice versa. Accessing a Qtproperty would for example create a QVariant, that would then need to beconverted to a V8::Value. If the variant was a string this involvedcopying the string data. To soften this, various caching mechanisms wereintroduced, but those came at the cost of increased memory usage andadditional complexity in the code. - QML scoping rules
QML is syntactically a tree of items. Inner items implicitly seeproperties of outer items leading to a well defined scope chain.Unfortunately this scope chain works differently then traditionalJavascript and couldn’t be directly implemented with existing Javascriptengines. The only way to do it directly would have been through nestingslow and deprecated with() statements. The current solution involves avery intrusive patch to V8 and still requires all QML properties to belooked up by name. - Throwing away QML type info
QML as a language has type information. Javascript however is completelyuntyped. This lead to the fact that all type information got thrownaway at QML compile time. Retaining the type information would allow usto optimise QML expressions a lot better. - iOS and WinRT support
iOS does not allow making memory both executable and writable, somethingthat existing JS engines require. WinRT doesn’t allow making memoryexecutable at all. This makes it impossible to use V8 on these platformswithout writing a full interpreter backend to V8. - Working with upstream V8
As said above, we are currently forced to maintain a rather large andintrusive patch set on top of V8. There is no chance of merging thesepatches upstream, as V8 fully focuses on the browser use cases.
These different arguments have lead to a research project that wasstarted Roberto Raggi and Aaron Kennedy in Nokia around a year ago,where they explored the feasibility of having a JS engine that istailored to the use cases QML requires. The project with the codenamev4vm was then transferred to Digia, where Simon, Erik and myself took itup and continued with it. It lived as a playground project onqt-project.org for the last couple of months.
Today we integrated this research project into a development branchof Qt Declarative, and we will continue to work on it there from now on.
The new engine contains a fully compliant ECMAScript 5.1implementation, that runs on all platforms Qt supports. It contains aJIT that currently works on
Linux, Mac and iOS. Integration into thecurrent QML engine is currently done through a V8 compatible API layerwhich we plan to remove in the coming weeks. The engine can run all QtQuick demos (with some minor glitches).
One of the things to note is that the engine is focused at QML usecases. This implies that we expect QML performance to become a lotbetter then it is today. Pure JS performance will on the other hand notbe quite as good as what you get with V8 as a backend.
Still our current benchmark numbers are very promising also for pureJS code. The V8 benchmark runs currently around three times slower thenthe JS engine used in Qt 4.8 and Qt Quick 1, and we see a lot ofpotential for further optimisations.
Details about the new engine and our future plans will come in afollowup post. You can find the code in the wip/v4 branch in theqtdeclarative repository. Feel free to play around with it. If you wantto join development, feel free to contact us on #qt-v4vm on freenode.
