[Development] Item creation time in QML

[Gunnar Roth]

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?
 
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.
 
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 <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 <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/a0f349c3/attachment.html>