[Development] QTBUG-43096 - QML instantiation performance decadence

Fri May 25 15:20:48 CEST 2018

Hi,

And to add what Robin said, solely focused on the task in question that was closed:

I ran benchmarks comparing a release build of 5.12 against 5.1.1 and ran the benchmark mentioned in the task, where Qt 5.12 came out in average faster by a factor of 4.

More details as well as the concrete run results are in the JIRA ticket. I do consider the concret QML object instantiation performance decadence to be resolved.

Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Robin Burchell <robin.burchell at crimson.no>
Sent: Friday, May 25, 2018 2:30:05 PM
To: development at qt-project.org
Subject: Re: [Development] QTBUG-43096 - QML instantiation performance decadence

Hi Uwe,

I had predicted a response, so this mail comes as no surprise to me :)

Personal opinions on various things ahead, the reader may disagree with me, that's perfectly normal and OK.

>From my own perspective, I think Controls 1 was a well-intentioned mistake. It set out to fill a perceived hole in what QML/Quick offered, but it took some shortcuts getting there, which were no doubt unavoidable due to various reasons - if nothing else, the times were rather turbulent in the Qt world at the time. The end result of this was not something pretty, when looking at the pile of things like ScrollView regressions, usually a few per release, before even getting to performance concerns.

Unfortunately, of course, since it existed, it got used - despite the shortcomings - though I would say that they likely made themselves very obvious without looking too hard.

At this point, from my perspective, QQC1/QQC2 is largely water under the bridge. I have over the years avoided using QQC1 in several projects as I knew that the performance simply wasn't up to the task without ever trying it "seriously", instead developing custom controls or - now that it is available - using QQC2 where appropriate - so unfortunately, I won't really be able to comment much on that "excitement" except to say that I am happy that QQC2 exists, and I look forward to its continued growth and maturity to fill the gaps with QQC1 where possible and necessary.

This leads me onto topic #2, which is QML's performance itself, and to me, this is a much more interesting topic, and where my own personal concern in the 5.1 -> 5.2 transition came into play. I experienced first-hand a lot of pain in those times and, realistically speaking, I don't think things really started to settle down until some years later.

With the benefit of hindsight, I don't personally think that the engine transition from 5.1 to 5.2 went well, but on the other hand, people are human, and will make mistakes - the important thing is to learn from those mistakes, and not repeat them. As well as that, there were no doubt a number of contributing factors then, similar to QQC1's.

That's quite far in the past, though. Nowadays, there has been a lot of work around the performance area, and it has continued to improve. There's also tracking of performance, to help avoid regressions in the area in future. These are the key reasons I closed the bug -- I think that the message has been heard, improvements have been made, and hopefully things are now consistently heading in the right direction.

You mention qskinny. I think that experimentation is very cool, and it's great that it is working out for your project, and I am already familiar with it, but I'm not too interested in it personally, simply because the QML of "today" (having written a few libraries LOC of QML at this point) generally works well enough for me, and I find the convenience of the language very much worthwhile. I suppose it is also my role to be a cheerleader of sorts for this thing, so there's that. ;-)

Even if our opinions differ though, I'd like to thank you for providing your perspective and story - it is not a surprise to me as I hope I have spelled out given the history of things, but it is interesting to hear. While I hear a lot of reluctance in your mail, I would encourage you to give QML another try in the future, and seeing how it goes for you. If there are things that you find surprising or unpleasant in the performance area, by all means, keep filing issues. Just because that one bug is closed doesn't mean the story is over: performance is a crucial feature in product development, and it is something that we must remain vigilant about, and work on continuously. :-)

Thanks for the mail,
Robin

--
  Robin Burchell
  robin at crimson.no

On Fri, May 25, 2018, at 1:12 PM, Uwe Rathmann wrote:
> Hi all,
>
> this morning I got a notification about
> https://bugreports.qt.io/browse/QTBUG-43096
> being closed. I guess many applications had been hit by this issue, but
> as I was related to the project that created this bug I would like to
> give my summary of what has happened since then:
>
> a)
>
> On the Qt development side a lot of efforts have been made to improve
> the QML problem. I don't want to be disrespectful, but the fact, that
> Controls 1 has finally become deprecated, because of ( IIRC )
> "insolvable performance problems", it is fair say, that those were no
> game changers.
>
> So to me the only step that really matters was introducing Qt/Quick
> Controls 2.
>
> But what makes Controls 2 being superior compared to its predecessor ?
> AFAIK the answer is mostly about doing less QML, achieved by:
>
> - dropping features ( usually desktop related )
> - internally done in C++
>
> Of course this raises the question, why there is no offer for doing more
> in C++ on the application side, when it has been identified as the
> solution for implementing the controls ?
>
> And this is why I'm disappointed about Controls 2. Application code still
> has to be done in QML and when the majority of the GUI code is
> application code the benefits of Controls 2 are limited.
>
> b)
>
> On our side the the decision was made to go back to Qt 5.1, where the
> project is stuck until today.
>
> Almost all developers of the original team are gone - none
> of them recommending QML as technology for further projects. Even worse
> - some of them explicitly mentioned QML being a reason for leaving.
>
> So for the next generation of our product we started to implement our
> own framework on top of the C++ part of Qt/Quick (
> https://github.com/uwerat/qskinny ). Our user interface today consists
> about ~200K lines of code ( pure C++ ) and so far I can say that the
> typical problems of having a bad startup performance or the heavy memory
> footprint simple don't exist.
>
> Unfortunately we still have to maintain our previous product written in
> QML for many years. Maybe we can migrate it step by step to our new
> framework.
>
> With all respect,
> Uwe
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180525/81e71687/attachment.html>