Hi, Some notes from the final day. - Peter made his first edit in the QtScript wiki (http://developer.qt.nokia.com/wiki/V8_Port), and submitted V8 RegExp bug reports
- Zoltan continued to work on his patch for implementing QScriptProgram using v8::ScriptData (http://qt.gitorious.org/+qt-developers/qt/qt-script-ng/merge_requests/1) - Found that the approach actually seems to make performance worse - V8 caches scripts internally, and supplying ScriptData only slows it down (V8 will perform validation of the ScriptData after consulting the cache) - We don't know / can't rely on when exactly the cache will be cleared - Need more benchmarks to determine the specific use case(s) where using QScriptProgram instead of string-based evaluate() is guaranteed to improve things - Discussion about QML's custom ("mini-")VM for small binding expressions, vs implementing the bindings using QtScript - We seem to have reached consensus that the custom VM is a good thing - Exploits object hierarchy and type information that JSC or V8 can't - Representation (byte/JIT code) will be more compact (because of static type information) - Such small expression is not a use case JSC/V8 was designed for - Conclusion: The custom VM is orthogonal to general-purpose JS support in QML (i.e. QtScript is not competing with it) - Zoltan argued that all this mixing of C++ and JavaScript doesn't seem like a viable solution - JavaScript engines want to execute JavaScript (that's what they do!) - QML core is C++, so the QML engine wants to execute C++ - Going back and forth between JS and C++ all the time means a lot of useless work, and it won't perform optimally - I.e. there's a reason why V8 implements most of the ECMA objects in JavaScript, not C++ - But Olivier thinks that the overhead of going to C++ maybe isn't that big :-) - ABI conformance etc... - How to deal with the code/feature duplication in QML's QObject binding vs QtScript's binding? - It's a problem regardless of whether we use JSC or V8 (look at Qt/master) - Consensus that we want a unified solution, and that the core bindings should be QtScript - QML can configure the bindings to do "extra stuff" it needs - QScriptClass vs QScriptDeclarativeClass, QScriptValue vs QScriptDeclarativeClass::{Value,Object}, QScriptString vs QScriptDeclarativeClass::Identifier - Caio: Can we fix the public QtScript class so they're as fast as QScriptDeclarative*, or adopt QScriptDeclarative*? - Kent: We did try already, maybe deserves a second look - Adopt the QScriptDeclarative classes as the "new" public classes for next generation QtScript? - We spend a lot of time trying to decipher all the stuff that QML does in its JS bindings - Mixture of static properties and dynamic behavior ("override"/scope objects et al) - It would be much more effective to get a core QML developer in the same room and go through the code and use cases - Kent to figure out if anyone can/wants to travel (either we go to Australia, or they come here) - Zoltan argued that there can be advantages to us sticking with JSC - Szeged guys have gained trust in the WebKit community - They could help us accelerate the process of extending the JSC C API - Commits in WebKit trunk the last weeks show that JSC is moving along - Discussion on next steps - Caio: We need to start proving that the V8-based approach has the potential of being as fast or faster than Qt/master - We have most of QML running on QtScript/V8 now, so it's time to focus on performance - If we keep going like we have, and get to 100% feature/behavioral completeness, but only _then_ find that performance is .5x that of Qt/master, we haven't solved anything - Should we switch to QtQuick2 branch? - Kent tried to do a merge locally; practically no conflicts (since we didn't touch src/declarative) - Merging down the road (when we start changing QML implementation) will be a lot harder - Olivier: Having a stable QML is the most important for us right now - Hence, we stick to tracking Qt/master - Start "porting" relevant parts of QML/QObject binding to QtScript (http://bugreports.qt.nokia.com/browse/QTBUG-18210) - Push for getting relevant benchmarks from QML camp Regards, Kent _______________________________________________ Qt-script mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-script
