Qt-contributors-summit-2013-QML-engine

From Qt Wiki
Revision as of 17:23, 6 January 2017 by EdwardWelbourne (talk | contribs) (Categorize)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

(Incomplete) transcript:

Problems with v8:

  • Massive memory consumption – v8 is optimized for big apps
  • High costs for property conversions etc

Aaron Kennedy, Roberto Raggi started research project. "Can't be that hard to write a JavaScript JIT compiler". Lars, Simon took over after 5.0 release. But we already have had a working excellent JavaScript parser (only smaller bugs fixed). We then had a compliant JavaScript engine end of February. Blog post about performance numbers … we're not there yet performance wise, but lots of stuff to optimize.

Big advance is no conversion costs (all e.g. work on QString). Also, QML is (mostly) strong typed, but we threw that information away with v4. Erik has been doing a lot of type information to add intermediate type information for optmizing code.

Finally we threw out the v8 dependency, and tried to get things working. After one week we had samegame running.

Last couple of weeks spent on fixing bugs, very close to be integrated in development branch.

Two backends right now: Interpreter (running bytecode), JIT using Macro assembler of JavaScriptCore. Latter one is actually pretty portable across systems.

Huge reduction of code base. So far we had 3 ways of evaluating bindings: v4 optimzier, snippets with sideeffects, other bindings, all replaced by v4m. We also can finally only parse the QML text once.

With v4 we can also put finally the qml object on top of the global JavaScript object. With v8 that wasn't possible, which was the reason why the global object is locked.

There's also now no problems anymore with different engines in different threads … that didn't use to work.

Ideas/Pans:

  • Replace vme directly with JITed code. How about storing bytecode in file (compiled QML)? Possible, but not easy – data structures aren't easy to dump right now.
  • Simplifying the lookup context chain.
  • We've to figure out what to do with the property cache.
  • Add more API to QJsEngine/QJsValue to be a 90% replacement of QtScript
  • Further optimizations for property accesses. E.g. directly call getters for C++ properties?
  • Tracing of dependencies – right now there's lots of interception going on. Maybe explicitly register proerty accesses in JIT code.
  • Optimizing integer arithmetics – right now everything is converted to double.

Situation on iOS? Jitting works … if started from xcode. Fallback is interpeter. Mid term QML might be compiled at compile time.

Help is appreciated!

Retrieved from "https://wiki.qt.io/index.php?title=Qt-contributors-summit-2013-QML-engine&oldid=29631"