[Development] Qt6 source changes

Lars Knoll lars.knoll at qt.io
Fri Nov 2 10:17:53 CET 2018


On 2 Nov 2018, at 10:10, André Pönitz <apoenitz at t-online.de<mailto:apoenitz at t-online.de>> wrote:

On Fri, Nov 02, 2018 at 08:20:39AM +0000, Ulf Hermann wrote:
Depends on usage.

See e.g. 551efd91990e07902e5324f720cf5585865c323d

   QmlProfiler: Use QList for QmlRange container when loading .qtd

   As we are using this as a queue, with many calls to takeFirst(), a
   QVector is prohibitively expensive here.

I should have used QQueue there, and that will hopefully still be a
linked(-ish) list in Qt6. Or it might become a ring buffer, but please
not a plain vector.

If we don't want to keep QQueue, I will still have the option to use an
equivalent std container there (+/- implicit sharing).

I am not saying that QVector or QList is the best container here,
it was just an example for a (rare...) case where a substitution
introduces a significant performance regression in real life.

Yes, I agree that those are possible. But should that stop us from doing changes that will improve things in 98% of the use cases? Hopefully not.

One concern here is also that the kind of regression can be hard to
discover as compilation succeeds, systematic performance testing
is often not done, and any manual testing before release usually
uses only smaller-than-normal sample sizes. So the first one to
notice the problem is the user of the code.

Well, maybe we can try to help here, e.g. by adding a special #define that would generate compiler warnings for takeFirst() and other calls that have a different performance characteristic in Qt 6 than in Qt 5. That would give people the option to find those cases more easily.

Cheers,
Lars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181102/6ffdbf8d/attachment.html>


More information about the Development mailing list