> I didn’t do any measurements, but quick search for QList in Qbs > source code shows a lot of places where it’s used incorrectly – > it stores «big» structures, std::shared_pointers, even all > QSharedDataPointer classes are not marked as Q_MOVABLE_TYPE > and thus result in extra allocations in QLists… > > My point is - current usage of Qt containers in Qbs should be > carefully revisited, switching to more suitable containers > (QVector or std::vector/std::deque).
I think we should know the performance hot spots first, before going to spend effort on doing broad code changes where it’s not affecting performance at all (which is typically true for 95% of the code). We should use tools like VTune to identify these hot spots and possibly segregate them, then focus on optimizing the sensible parts only. Thomas Von: Qbs <qbs-boun...@qt-project.org> Im Auftrag von ???? ?????????? Gesendet: Donnerstag, 16. Mai 2019 01:25 An: Christian Gagneraud <chg...@gmail.com> Cc: qbs <qbs@qt-project.org> Betreff: Re: [Qbs] Donation to QBS developers/maintainers/contributes In many cases, you don’t need to copy them. For trivial getters, you can return const-ref/span to the internal vector instead of a copy because in many places all we do is iterate over that vector. The only argument for copies is that it’s impossible to change the implementation from returning a member to some «transformed member» without breaking BC. Well, so far Qbs didn’t do any promises about BC so I don’t think it’s relevant. This will save us from creating a temp variables or usages of qAsCont to avoid detaching in range-for loops (see this commit https://codereview.qt-project.org/#/c/253792/ to estimate the amount of incorrect usages of Qt containers). Note, that those clutter API as well, especially the need of a temp variable. I didn’t do any measurements, but quick search for QList in Qbs source code shows a lot of places where it’s used incorrectly - it stores «big» structures, std::shared_pointers, even all QSharedDataPointer classes are not marked as Q_MOVABLE_TYPE and thus result in extra allocations in QLists… My point is - current usage of Qt containers in Qbs should be carefully revisited, switching to more suitable containers (QVector or std::vector/std::deque). 16 мая 2019 г., в 0:00, Christian Gagneraud <chg...@gmail.com<mailto:chg...@gmail.com>> написал(а): On Thu, 16 May 2019 at 09:32, Иван Комиссаров <abba...@gmail.com<mailto:abba...@gmail.com>> wrote: 15 мая 2019 г., в 19:50, André Pönitz <apoen...@t-online.de<mailto:apoen...@t-online.de>> написал(а): Getting rid of implicitly shared containers should be a rather obvious move when "performance" is part of any "final picture", coherent or not. +1 from me, hidden detaches are evil =) How do you avoid copy then? Without cluttering an API. Chris
_______________________________________________ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
