Table of Contents

Storage of QML defined properties explained (Part 1)

It all started with a simple question:

How much does a property you define in QML code cost in terms of memory? 

This led me down a merry chase into the source of the QML engine. The result is this article and in the end a contribution to Qt5.6.

Before we get started, let’s do a quick recap of what we know about Qt properties on the C++ side. Qt has compile time properties which can be added to QObject derived classes. The various methods associated with such a property (read/write/reset/notify/…) are specified using the Q_PROPERTY macro. The properties themselves are typically stored as C++ member variables. They integrate with the meta object system and are therefore also accessible from the QML-side.

Back to the initial question: how much memory is needed for a QML defined property? To answer this, one first needs to figure out how and where they are

stored. The QQmlVMEMetaObject class, which is instantiated for each QML object, takes care of that.

The constructor of QQmlVMEMetaObject contains this line.

data = new QQmlVMEVariant[metaData->propertyCount - metaData->varPropertyCount];

This gives a hint that we will probably have to differentiate between typed (non-var) and var properties.

Let’s look at typed properties first. So for each typed property the QQmlVMEMetaObject allocates a QQmlVMEVariant. The QQmlVMEVariant class is local to the translation unit of the QQmlVMEMetaObject. 

Let’s have a look there.

class QQmlVMEVariant
    // [...]
    inline QObject *asQObject();
    inline const QVariant &asQVariant();
    inline int asInt();
    inline bool asBool();
    inline double asDouble();
    inline const QString &asQString();
    inline const QUrl &asQUrl();
    inline const QTime &asQTime();
    // [...]
    inline void setValue(QObject *v, QQmlVMEMetaObject *target, int index);
    inline void setValue(const QVariant &);
    inline void setValue(int);
    inline void setValue(bool);
    inline void setValue(double);
    inline void setValue(const QString &);
    inline void setValue(const QUrl &);
    inline void setValue(const QTime &);
    // [...]
    int type;
    void *data[8]; // Large enough to hold all types
    // [...]

This looks promising. The interface contains various methods to get/set types which are also basic QML types. Let’s see where this is used by looking at the asBool()/setValue(bool) methods.

This leads us to:

int QQmlVMEMetaObject::metaCall(QMetaObject::Call c, int _id, void **a)

Assumption: To read for example a bool typed property, metaCall() is invoked with c == QMetaObject::ReadProperty. _id contains the index of the property in the array of QQmlVMEVariant we allocated earlier (and assigned to the data member variable). a is the destination where the property value should be read into.

if (c == QMetaObject::ReadProperty) {
    switch(t) {
    // [...]
    case QVariant::Bool:
        *reinterpret_cast(a[0]) = data[id].asBool();
    // [...]

By setting a breakpoint and loading a simple test QML we can quickly validate that this is actually the right place (the write case is very similar so I will leave it as an exercise for the reader).

For brevity I will leave out the implementation for asBool()/setValue(bool) but if you have a look at it you will notice, that it stores the bool value in these two members of the QQmlVMEVariant:

    int type;
    void *data[8]; // Large enough to hold all types

This allows us to already answer the initial question. How much memory does it take to store a simple QML defined property?

The answer is sizeof(void*)*8 + sizeof(int), which is 36 bytes on a 32bit system and 68 bytes on 64bit system. Taking into account structure padding at the end of the QQmlVMEVariant this will end up at 72 bytes on a 64bit system.

This is quite a bit more than we would have expected. The next part of this series will explain why the QQmlVMEVariant is that large, how var properties are handled and how the current situation can be improved.

Sorry, comments are disabled on this post.

Frank Meerkötter

Frank Meerkötter

Frank Meerkoetter is the Development Lead for basysKom GmbH, where he is consulting customers on industrial and embedded applications, often in combination with Qt. He is responsible for the technical consulting, system- and software-architecture within basysKom. He is the maintainer of Qt OPC UA and a contributor to the Qt project. He has a strong background in Embedded Linux, systems programming, distributed systems and application development. He holds a Master of Computer Science from the University of Applied Sciences in Darmstadt.

Read more

Jeremias Bosch
Speedup your Qt/QML list scrolling on lowend devices

Something that has traditionally been complicated to achieve in Qt/QML, especially on low end hardware, is high performant list scrolling with complex delegates.
This has recently changed. In Qt 5.15, it is as simple as setting the new QML ListView property called reuseItems to true. For more details, have a look at the documentation.
In this blog post, I will explain how you can implement this feature in Qt Versions prior to 5.15.

Read More »
IoT Cloud
Heike Ziegler
IoT: Getting started with cloud and modern IoT and IIoT from scratch

IoT and IIoT applications are special compared to other kinds of cloud applications as they have to deal with devices existing “outside” of data centers.

The following series of articles provide an end-to-end overview of what Microsoft Azure offers to handle some of the challenges involved in connecting an IoT Device with the Cloud.

By working through this series you will learn about the major concepts involved in getting your IoT/IIoT device connected to Microsoft Azure. In our examples we will feature Qt, Node.Js, Protobuf from Google and much more to get you started.

Read More »
Python Qt
Sumedha Widyadharma
Using Shiboken2 to create Python bindings for a Qt library

With the release of Qt 5.12, Qt for Python is officially supported and can be used to write full-fledged Qt applications using Python as the main programming language.

This prompted us to also take a closer look at the bindings (the Python module is called PySide2) and also the underlying technology, namely the binding generator called Shiboken2.

Read More »