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...@qt-project.org> on behalf of Uwe Rathmann <uwe.rathm...@tigertal.de> Sent: Saturday, May 26, 2018 12:30:11 PM To: development@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
