On 2 Nov 2018, at 10:10, André Pönitz <apoen...@t-online.de<mailto:apoen...@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
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development