QStringLiteral optimization
-
wrote on 15 Dec 2023, 08:18 last edited by
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
-
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. -
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
@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 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.
wrote on 15 Dec 2023, 08:23 last edited by@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
-
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
wrote on 15 Dec 2023, 08:23 last edited by JonB@Redman
So far as I know, if you wrote insteadinline const static QString tableName = QString("users");
the runtime would still have to callQString()
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
almostirrelevant,. 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. -
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
@Redman said in QStringLiteral optimization:
inline const static QString tableName = QStringLiteral("users");
Why not
inline const static QString tableName{"users"};
-
@Redman said in QStringLiteral optimization:
inline const static QString tableName = QStringLiteral("users");
Why not
inline const static QString tableName{"users"};
wrote on 15 Dec 2023, 08:26 last edited by JonB@jsulm
As I wrote, and the OP is asking, does that not still callQString()
converter at start up (or wherever depending on where the line is placed)? Isn't the point ofQStringLiteral()
(which I have never bothered to use) that it does the work at compile-time instead? -
@jsulm
As I wrote, and the OP is asking, does that not still callQString()
converter at start up (or wherever depending on where the line is placed)? Isn't the point ofQStringLiteral()
(which I have never bothered to use) that it does the work at compile-time instead?wrote on 15 Dec 2023, 08:30 last edited by@JonB
Thats right. Here is a good explanation https://woboq.com/blog/qstringliteral.html -
@JonB
Thats right. Here is a good explanation https://woboq.com/blog/qstringliteral.htmlwrote on 15 Dec 2023, 08:34 last edited by@Redman
Indeed. But nonetheless my earlier post still stands: yes, useQStringLiteral()
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. -
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
As I wrote, and the OP is asking, does that not still callQString()
converter at start up (or wherever depending on where the line is placed)? Isn't the point ofQStringLiteral()
(which I have never bothered to use) that it does the work at compile-time instead?@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
-
@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
@jsulm Since QString doesn't have dedicated initializer_list constructor
QString tableName{"users"}
is the same asQString tableName("users")
. It just callsQString(const char *str)
, which allocates and does conversion viaQString::fromUtf8
. -
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.Lifetime Qt Championwrote on 15 Dec 2023, 09:22 last edited by 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. -
1/12