[Development] HEADS-UP: QStringLiteral

Martin Smith Martin.Smith at qt.io
Thu Aug 22 15:41:51 CEST 2019

But Marc, your last paragraph calls for separating the API and implementation discussions, but the paragraph just before it argues that the API to work around our slowness is vital.

If Qt developers must not forget Q_DECLARE_TYPEINFO, why isn't it important for users?

Should we have a pre-Qt 6 optimization period, where you first write up an exhaustive list of all the implementation optimizations that should be used in all Qt library code, and then we take the time to ensure that every class uses them?

I'm still not seeing why these same optimizations shouldn't be important to describe in the Qt  documentation for users. Users look at the Qt source code, so when they see Q_DECLARE_TYPEINFO, they should be able to find out what it does.

From: Development <development-bounces at qt-project.org> on behalf of Mutz, Marc via Development <development at qt-project.org>
Sent: Thursday, August 22, 2019 3:11 PM
To: Qt development mailing list
Subject: Re: [Development] HEADS-UP: QStringLiteral

On 2019-08-22 14:48, Martin Smith wrote:
> Now that we use clang in Creator and QDoc, suppose we write a QString
> source code analysis tool using clang. The tool would parse sources
> looking for uses of QString and then analyzing the code patterns where
> QString is used to find possible optimizations using the other Qt
> string classes.
> The output is a report suggesting the possible optimizations. Then we
> can tell customers to write code with QString first, because that's
> easy. When it works, run this tool and see where you can improve
> performance and which string classes to use.

Yes, that tool is called Clazy :)

Please note that I, the thread starter, never claimed that users should
need to know all about QL1S, QSL, QSV, ... but Qt developers should. I'm
totally fine with users writing

   QHash<QString, QString> map;
   map["one"] = "uno";
   map["two"] = "due";

At the same time, I find that this is utterly unacceptable in library
code, ie. Qt implementation.

We need to collectively understand that implementing a library is
different from the library's API and from use of the API. Anyone who
thinks otherwise is invited to have a look at qmetatype.h or
qtypeinfo.h. All users see from this is Q_DECLARE_METATYPE, and we don't
really care whether they use Q_DECLARE_TYPEINFO. But a Qt developer
mustn't forget to add Q_DECLARE_TYPEINFO, because it's a BiC change to
add it afterwards, and there are tons of Qt optimisations hinging on
getting that correct. Qt developers are under very different constraints
than Qt users, and we can't go on pretending that it's ok to develop Qt
as if we were developing a throw-away Qt app and that profiling will
show us where to optimise.

We can't profile all Qt applications out there, so the chance is high
that _some_ Qt implementation will be a bottleneck for _someone_. And if
that someone can't work around our slowness, they will use a different
tool, or will have to write their own. If they succeed in doing so
without a huge invest of resources, they will ask us: "if it was so easy
to make this 50% faster, why did I have to do this, why isn't this in Qt
already"? No-one can seriously want that.

So, I'm really disappointed, and I'm not intending to single you out
here, Martin, but it seems to me that well-meaning emails regarding Qt
_implementation_ are hijacked and transformed into discussions about Qt
_API_. We should have these discussions, both of them, but we mustn't
conflate these two very different aspects.

Development mailing list
Development at qt-project.org

More information about the Development mailing list