[Development] QTBUG-43096 - QML instantiation performance decadence

[Jean-Michaël Celerier]

> Jędrzej had a beautiful proof of concept at some point for QObject to
combine the object and d-pointer allocation into one.
If only there was a way to be able to use Qt without all the PIMPLing and
just have QObjectPrivate be a "normal" QObject member !




-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Sat, May 26, 2018 at 2:05 PM, Simon Hausmann <Simon.Hausmann at qt.io>
wrote:

> 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
>
> _______________________________________________
> 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/65db5d27/attachment.html>