[Development] QList

[Martin Smith]

>It's not the application developer's task to avoid the death by a thousands Qt

>paper cuts. It's Qt's job.


Ok, but I'm the customer, and I am always right. I want my application that uses QList to continue to run in Qt 6 with QList just like it did in Qt 5. If it speeds up or slows down or uses more memory or less, I don't care as long as it still passes my old requirements.


What is your solution?


martin

________________________________
From: Development <development-bounces+martin.smith=qt.io at qt-project.org> on behalf of Marc Mutz <marc.mutz at kdab.com>
Sent: Monday, March 20, 2017 2:13:30 PM
To: development at qt-project.org
Subject: Re: [Development] QList

On Monday 20 March 2017 13:42:09 Martin Smith wrote:
> >Qt must have acceptable performance for end user applications to be able
> >to have acceptable performance at all - whether or not it is a priority
> >to those developers.
>
> I write an application that has two performance requirements:
>
> 1. It must complete execution in 1 minute.
>
> 2. It must not run out of memory.

Sorry for highjacking your mail, I know this is hardly related, but seeing
"application" here, I need to repeat the following:

We're talking about Qt here. Qt is not an application. Qt is a library.
Different users use it differently. You cannot predict what will be the
bottleneck for any given user, thus you have to optimise everything. We don't
have the man-power to optimise everything, so we must settle for _not
pessimising_ anything. But Qt in the past has pessimised way too much, be it
Q_FOREACH, QList<QVariant>, CoW, ... We need to stop pessimising the common
tasks to optimize uncommon ones.

If someone copies a std::vector with a million elements by value in a tight
loop, any profiler in the world will be able to pinpoint that hotspot, and the
developer is happy, because the fix is easy.

OTOH, no profiler in the world will ever pinpoint to the developer the
slowdown caused by using QVector or QList in normal usage patterns. As a
result of Qt's sloppiness, your application is 2x slower than it could be,
with no indication as to why. You need to have good luck and a very powerful
(and expensive) profiler to have a chance to find that QVector performs worse
than std::vector in general. Worse, you can't do anything about it, because
replacing one QVector with std::vector has neglible effect. With luck, if you
replaced all you'd get a 20% speedup (I'm totally making these numbers up),
which disqualifies this work for an application developer as having
deminishing return of investment.

It's not the application developer's task to avoid the death by a thousands Qt
paper cuts. It's Qt's job.

Our job.

Thanks,
Marc

--
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
_______________________________________________
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/20170320/9b63e1d3/attachment.html>