2

I am currently using properties, declared in the root qml file, and they work globally, because of dynamic scoping, but I am worrying that eventually they will pose too much lookup overhead, especially as the object tree grows deeper, which it eventually will.

There is also the possibility to use a context property object, however that increases verbosity, and also:

The disadvantage is that the v4 engine can not deal with dynamic objects, for example those exported from C++ via setContextProperty(). A binding containing such a dynamic object will be part of QV8Bindings.

From what I've read singletons should be even more efficient in terms of lookup performance, but they are even more verbose - requiring both import statements and accessing individual properties as singleton members rather than directly, and last but not least there is also the age old yet still unfixed QTBUG-34418 which is detrimental when using QML over network.

So what would be the most efficient way to implement a set of global properties in QML, considering the following criteria:

  • lookup performance
  • ease of use / low verbosity
  • compatibility with Settings to make the value changes persist across application runs
  • must support value change notifications and automatic binding updates
dtech
  • 47,916
  • 17
  • 112
  • 190
  • What is v4 engine? I use dynamic objects exposed from C++ via `setContextProperty e.g. m_quickView.engine()->rootContext()->setContextProperty("msgBoard", MyQmlMsgBoard::instance());` and don't see any performance hit. – Alexander V Dec 29 '16 at 23:30
  • @AlexanderVX - v4 is the new significantly faster evaluation engine that was written to avoid the v8 JIT overhead and licensing complications. It is supposed to be significantly faster for the evaluations of simple expressions, such as simply getting some object's property. – dtech Dec 29 '16 at 23:35
  • I would first measure the lookup time. How many microseconds does a lookup take? Then I would implement my own hash map (some solution like listed here: http://stackoverflow.com/questions/3300525/super-high-performance-c-c-hash-map-table-dictionary) and compare my method against Qt's default. Then if my own hash is much quicker I would implement it as a QML type, and use this type as a gate to bypass the QML property system. – Nulik Dec 30 '16 at 01:07
  • @Nulik - the point is that there is no lookup really needed here, I am interested in one and one value only. The QML's engine is already as fast as it gets, but being a dynamic lookup, it still does work that I need to avoid, especially considering that in the final stage there will be trees hundreds of objects deep. There is no point traversing all of this to get to the value. – dtech Dec 30 '16 at 01:31
  • Whether lookup performance is an issue will likely depend on how you are using these properties. If they are used in bindings then the lookup is probably a one time effort, i.e. at binding creation time. – Kevin Krammer Dec 30 '16 at 11:02
  • @KevinKrammer - the properties are used to style and format a dynamic UI that the user can change during the runtime. It can have thousands of UI elements, all bound to the style settings properties, elements are created dynamically depending on the usage pattern, so there can be thousands of evaluations per second and that's even without changing the property values. And when that happens there are potentially tens of thousands of evaluations. – dtech Dec 30 '16 at 17:12
  • @ddriver When you write "evaluations" do you mean property reads or creating new bindings? If the former, did you check if that even involves name resolution? – Kevin Krammer Dec 31 '16 at 08:49
  • @KevinKrammer - according to the profiler, each new object that uses the binding results in a binding evaluation. If the binding is evaluated, that implies that a lookup is performed, one that goes all the way down the object tree to the root object. According to the documentation, there is a lookup involved even when referencing properties that are in the particular QML file. And it goes without saying, but when that property changes value, all the objects that are bound to it will have their bindings reevaluated. – dtech Jan 01 '17 at 17:11
  • @ddriver I see. My guess was that the lookup for a property's "owner" was only done at binding creation. So evaluation of the binding would only be a value read – Kevin Krammer Jan 02 '17 at 09:14
  • Yes, the lookup of the owner is the primary concern. It is just a value read, even if it is some derivative of that value, I'd put one expression that evaluates it and caches it into a property that all the objects bind to rater than evaluating it in each and every object. – dtech Jan 02 '17 at 14:41

0 Answers0