[Qbs] Donation to QBS developers/maintainers/contributes

[Epting, Thomas]

> 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-bounces at qt-project.org> Im Auftrag von ???? ??????????
Gesendet: Donnerstag, 16. Mai 2019 01:25
An: Christian Gagneraud <chgans at gmail.com>
Cc: qbs <qbs at 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 <chgans at gmail.com<mailto:chgans at gmail.com>> написал(а):

On Thu, 16 May 2019 at 09:32, Иван Комиссаров <abbapoh at gmail.com<mailto:abbapoh at gmail.com>> wrote:

15 мая 2019 г., в 19:50, André Pönitz <apoenitz at t-online.de<mailto:apoenitz at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20190516/3406594f/attachment.html>