Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.
Qt-contributors-summit-2013-QML-engine: Difference between revisions
AutoSpider (talk | contribs) (Add "cleanup" tag) |
m (Categorize) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{Cleanup | reason=Auto-imported from ExpressionEngine.}} | {{Cleanup | reason=Auto-imported from ExpressionEngine.}} | ||
[[Category:QtCS2013]] | |||
(Incomplete) transcript: | (Incomplete) transcript: | ||
| Line 8: | Line 8: | ||
* High costs for property conversions etc | * High costs for property conversions etc | ||
Aaron Kennedy, Roberto Raggi started research project. | 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. | 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. | ||
| Line 20: | Line 20: | ||
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. | 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 | 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: | 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 | * 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. | * 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 | * 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? | * Further optimizations for property accesses. E.g. directly call getters for C++ properties? | ||
* Tracing of dependencies – right now | * 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. | * Optimizing integer arithmetics – right now everything is converted to double. | ||
Latest revision as of 17:23, 6 January 2017
| 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!