QStringLiteral optimization

Redman

QStringLiteral creates static data during compilation which safes us the QString overhead. But what about this usecase

inline const static QString tableName = QStringLiteral("users");

Does using QStringLiteral pose any performance gains here? Would this make the start of my app faster? Static variables get initialized first, so I'd assume we do actually have a performance gain

Chris Kawa

I'm gonna go a bit against my colleagues here and say go for it. Avoiding dynamic allocation is always a good thing, especially on platforms on which it's a very costly operation (can go in thousands of cycles on some embedded hardware).
Even if you don't see much of a difference on your particular platform it's simply a good habit to write code that is performant by default, especially when there's not much difference in code complexity associated with it.

Christian Ehrlicher

@Redman said in QStringLiteral optimization:

Does using QStringLiteral pose any performance gains here?

Compared to what?

Would this make the start of my app faster?

Your app will now start ten cpu cycles faster.

Redman

@Christian-Ehrlicher said in QStringLiteral optimization:

@Redman said in QStringLiteral optimization:

Does using QStringLiteral pose any performance gains here?

Compared to what?

inline const static QString tableName = "users";

Would this make the start of my app faster?

Your app will now start ten cpu cycles faster.

It's all about the UX

JonB

@Redman
So far as I know, if you wrote instead inline const static QString tableName = QString("users"); the runtime would still have to call QString() to do the conversion, just it would happen at the start of program execution (depending on where you write this).

In any case, the difference in start up will be ~~almost~~ irrelevant,. You would need "trillions" of these to make much difference. Worry about this "speed difference" if you are using a line like this in a function/loop where it's going to be called millions of times, not a one-off place.

If it really bothers you, just use QStringLiteral() on every literal string.

jsulm

@Redman said in QStringLiteral optimization:

inline const static QString tableName = QStringLiteral("users");

Why not

inline const static QString tableName{"users"};

JonB

@jsulm
As I wrote, and the OP is asking, does that not still call QString() converter at start up (or wherever depending on where the line is placed)? Isn't the point of QStringLiteral() (which I have never bothered to use) that it does the work at compile-time instead?

Redman

@JonB
Thats right. Here is a good explanation https://woboq.com/blog/qstringliteral.html

JonB

@Redman
Indeed. But nonetheless my earlier post still stands: yes, use QStringLiteral() here (and everywhere) if you want to squeeze the last drop out of speed, but don't kid yourself that in your case it will make the slightest difference to the UI or anything else.

Chris Kawa

I'm gonna go a bit against my colleagues here and say go for it. Avoiding dynamic allocation is always a good thing, especially on platforms on which it's a very costly operation (can go in thousands of cycles on some embedded hardware).
Even if you don't see much of a difference on your particular platform it's simply a good habit to write code that is performant by default, especially when there's not much difference in code complexity associated with it.

jsulm

@JonB said in QStringLiteral optimization:

does that not still call QString() converter at start up

Not since C++11 as far as I know, but not sure about QString. See https://en.cppreference.com/w/cpp/language/list_initialization

Chris Kawa

@jsulm Since QString doesn't have dedicated initializer_list constructor QString tableName{"users"} is the same as QString tableName("users"). It just calls QString(const char *str), which allocates and does conversion via QString::fromUtf8.

Christian Ehrlicher

@Chris-Kawa said in QStringLiteral optimization:

I'm gonna go a bit against my colleagues here and say go for it.

But this was not his question... there will be no startup speedup which is measurable for this single string. You're right that all the tiny things will maybe bring something but then the question was wrong (and in the first incomplete).
Yes, you should use QStringLiteral, but this is also written in the documentation: https://doc.qt.io/qt-6/qstring.html#QStringLiteral but there is a lot lot of other stuff which will affect your performance first before seeing any gain due to this change.