[Development] Item creation time in QML

[Gunnar Roth]

Hello Gunnar
yes i meant y-axis. 
ok so it is operations/frame and i assume a modern pc is used for Robin Burchells measurements as you did with using you MacBook Pro. 
After my vacation I will try to do execute  your benchmarking measurements on our wec2013 imx6 device, using 5.4 and qt 5.5 git. so i can see if we all see improvements here.
( I will ask a colleague to do similar on our im6 and omap linux devices)

but how do i get 5.5 git ? 
can i simply use :
	
git clone https://git.gitorious.org/qt/qt5.git qt5
cd qt5
git checkout 5.5
perl init-repository

??

Thank you very much for your efforts in making qml better and faster (again) . We had asked digia a long time for benchmarks, but did not get any good information
, then i found your blog last year giving us want we needed, an insightful designed benchmarking suite.well for some testcase we got a crash fair but all in all it was a good start.
we get involved with dig again with our results but … we will see.

Best regards,
Gunnar Roth


> Am 12.02.2015 um 19:25 schrieb Gunnar Sletta <gunnar at sletta.org>:
> 
> 
>> 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. 
> </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 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>
>> An: "Rutledge Shawn" <Shawn.Rutledge at theqtcompany.com>
>> Cc: "development at qt-project.org" <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> 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
>> 
>> > 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
>> http://lists.qt-project.org/mailman/listinfo/development
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>