[Development] QTBUG-43096 - QML instantiation performance decadence

[Simon Hausmann]

Hi,


Jędrzej had a beautiful proof of concept at some point for QObject to combine the object and d-pointer allocation into one.


That's where I had the idea that perhaps this idea could be extended all the way to QML, so that the instantiation of a .qml file would collect all object and d-pointer sizes at type compilation time and use a bumper pointer allocator during instantiation (assuming that we can verify upfront that the types support it).


The consequence would be one libc malloc for all objects per .qml file and pointer based APIs like anchors or gradients would involve no data copying at all, as opposed to value based gadget APIs.


This would require a static QObject parent-hierarchy and make a few other assumptions, but as long as they are the common case and can be detected, I think there are ways of making QtQuick elements instantiate faster and use less memory.




Simon


P.S.: Are you sure the stops: [ ... ] assignment works?

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Uwe Rathmann <Uwe.Rathmann at tigertal.de>
Sent: Saturday, May 26, 2018 12:30:11 PM
To: development at qt-project.org
Subject: Re: [Development] QTBUG-43096 - QML instantiation performance decadence

On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote:

> The first point I would make in reply, though, is
> that the convenience of creating code with a/b/c are going to be
> significantly better in my experience.

Code for d) look like this:
https://github.com/uwerat/qskinny/blob/master/examples/buttons/buttons.qml

IMHO the code for a/b would be very similar, the only one that requires
more work would be c as you need extra code for creating the button
itself.

> Let's take
> another good example from the top of my head: Item::anchors. Behind the
> scenes, it's implemented as a QQuickAnchors, which is a QObject. Let's
> turn it into a Q_GADGET, and we're done, right?

No, but please let's stay with gradients, where the answer is yes.

QSkinny offers this class to expose gradients to QML: https://github.com/
uwerat/qskinny/blob/master/src/common/QskGradient.h

Now when having an control with a property like this:

class MyRectangle : public QQuickItem
{
    Q_OBJECT

    Q_PROPERTY( QskGradient gradient READ gradient
        WRITE setGradient RESET resetGradient NOTIFY gradientChanged )

    ...
};

you can write your QML code this way:

MyRectangle
{
    gradient {
        orientation: "Vertical"

        stops: [
            { position: 0.0, color: "MediumAquamarine" },
            { position: 0.5, color: "..." },
            { position: 1.0, color: "DarkSeaGreen" },
        ]
    }
}

The equivalent code offered by Qt/Quick needs 4 QObjects - for each
instance of an item. So when having 100 rectangles these are 400 QObjects
- good for nothing.

Uwe

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180526/8db0f145/attachment.html>