Qt-contributors-summit-2013-QML-engine: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
(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 <span class="caps">JIT</span> 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, <span class="caps">QML</span> 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), <span class="caps">JIT</span> 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 <span class="caps">QML</span> 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 <span class="caps">JIT</span>ed code. How about storing bytecode in file (compiled <span class="caps">QML</span>)? 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 <span class="caps">API</span> 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 <span class="caps">JIT</span> 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 <span class="caps">QML</span> might be compiled at compile time. | |||
Help is appreciated! | |||
Revision as of 14:07, 25 February 2015
(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!