[Development] Item creation time in QML

[Gunnar Sletta]

> On 12 Feb 2015, at 18:03, Gunnar Roth <gunnar.roth at gmx.de> wrote:
> 
> Hi,
> after downloading it to my cell phone and picking it with usb connection, i was finally able to read pdf document.
> I am curious what the unit of the x-axis is in your diagrams, i fugure higher is better, but what is measured there?

Hi Gunnar :)

The x-axis is Qt version, did you perhaps mean y-axis? :)

From my original mail: 
<snip>
How the benchmark works is that the it tries to figure out how many operations of a given type is possible each frame (not per second) while sustaining a perfect 60 fps (or whatever other fps you target). For these numbers, we’re looking at delegation creation and destruction. You can look at the content of each specific benchmark here: https://github.com/sletta/stuff/tree/master/qml/benchmarks/benchmark/creation <https://github.com/sletta/stuff/tree/master/qml/benchmarks/benchmark/creation>. 
</snip>

> IMO QuickItemText is too complicated for the simple case, which is "displaying a single line of plain text of about 15 characters", as this is the most common case in a UI. So having a QuickSimpleText item, which can only do the simple case should be much faster to create. Not having a QTextDocument and all that many members for all this many features. Of course even with most of this feratures it was faster in 5.1, but still could be a lot more , i think for the simple case.

It still needs to do shaping and all that though, so some involvement with the text engine is required. However, I believe there is huge room for improvement there. There is https://bugreports.qt.io/browse/QTBUG-42853 <https://bugreports.qt.io/browse/QTBUG-42853> which covers some ideas around writing a faster implementation.

>  
> I am very interested in solving issue as in our environment we are hit by the degration and our product has to stay at 5.1 for now.
> So keep on the good work!
>  
> Best regards,
> Gunnar Roth
>  
> Gesendet: Donnerstag, 12. Februar 2015 um 11:56 Uhr
> Von: "Robin Burchell" <robin+qt at viroteck.net <mailto:robin+qt at viroteck.net>>
> An: "Rutledge Shawn" <Shawn.Rutledge at theqtcompany.com <mailto:Shawn.Rutledge at theqtcompany.com>>
> Cc: "development at qt-project.org <mailto:development at qt-project.org>" <development at qt-project.org <mailto:development at qt-project.org>>
> Betreff: Re: [Development] Item creation time in QML
> On Wed, Feb 11, 2015 at 2:49 PM, Rutledge Shawn
> <Shawn.Rutledge at theqtcompany.com <mailto:Shawn.Rutledge at theqtcompany.com>> wrote:
> >> Being able to do 500+items rectangles in one frame is decent, but not awesome. Being able todo 130 text items in one frame, is less than ideal, given that we often use several text items per cell in a list or table. Text is probably the most important UI element we have. Being able to do 10 buttons is, well, unfortunate :) If we look at Button, we see that it is a fairly complex QML beast. Hierarchy is
> >>
> >> Button -> BasicButton -> Control -> FocusScope
> >>
> >> and there are quite a bit of stuff on every level, including the dynamic style handling which will in turn create a StyleItem.
> >>
> >> And keep in mind that even though this isn’t the most high-end mac, it is sitll a pretty decent computer, Qt is supposed to run on much worse hardware than this.
> >>
> >> —
> >>
> >> There have been a few changes going into 5.5 which make these numbers better than 5.4, but I still think we got quite a ways to go.
> >
> > That’s very interesting.
> >
> > Do you think it was ever better in past versions?
> 
> I'm glad you asked: http://rburchell.com/QtQuickPerformance.pdf <http://rburchell.com/QtQuickPerformance.pdf>
> 
> > What do you think we should do about it? Mainly focus on trying to create fewer objects, or is there still a lot of headroom for making the creation more efficient? Is creation expensive because of constructor code, making too many signal/slot connections, or something else?
> 
> I think there's plenty that can be done, because it *used* to be
> better. We should aim for matching the performance we used to have at
> the very least, ideally, for exceeding that.
> 
> I'd say that one very particular case that needs attention is text
> performance. It's pretty bad.
> 
> As for why, specifically, it's slow, I did some profiling in the past,
> but I don't have those results now. I plan to spend some time on that,
> maybe on the weekend, and send some more information once that's done.
> _______________________________________________
> Development mailing list
> Development at qt-project.org <mailto:Development at qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development <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/20150212/fee6cca9/attachment.html>