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 <[email protected]>:
>
>
>> On 12 Feb 2015, at 18:03, Gunnar Roth <[email protected]> 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" <[email protected]>
>> An: "Rutledge Shawn" <[email protected]>
>> Cc: "[email protected]" <[email protected]>
>> Betreff: Re: [Development] Item creation time in QML
>> On Wed, Feb 11, 2015 at 2:49 PM, Rutledge Shawn
>> <[email protected]> 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
>> [email protected]
>> http://lists.qt-project.org/mailman/listinfo/development
>> _______________________________________________
>> Development mailing list
>> [email protected]
>> http://lists.qt-project.org/mailman/listinfo/development
>
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
