[Development] Using string literals in autotests

[apoenitz]

On Thu, Mar 28, 2024 at 12:14:35PM +0100, Friedemann Kleint via Development wrote:
> Hi,
> 
> I'd say performance should be a consideration for autotests since they are
> compiled and run over and over again in the CI. So, string theory should be
> applied to avoid unnecessary conversions and allocations. Even it is
> considered a minor optimization, it will have an impact on energy
> consumption & CO2 emission in the end, IMO.

I tend to disagree, at least to make this a first approximation to some general
rule, which IMNSHO rather should be "make the code easy to create and easy to
understand, micro-optimize only if you have evidence that the first approximation
is not sufficient".

Performance surely is a consideration in general, also for autotests, and there
are probably also a handful autotests that are so string-intensive (parsers?)
that string related optimization actually help, but at the end of the day,
this should be balanced against other costs, e.g. how quick and easy to write
and to maintain code, and it should not require a (recent...) "PhD in string
theory".

> Of course, writing a sophisticated template squeezing out the last bit of
> runtime performance on which the compiler has to chew for a while does not
> help either, since the test is typically compiled and run once.

And it's a full process that needs to be spawned etc etc. A few hundred, even
thousands, allocations do no make a noticable difference in a stand-alone test.
Even when run (optimistically) tens of thousands times in the CI this still
has to offset the human time to create and review changes for this "improvement",
and that's not even considering yet the recent tradition of changing the
prefered decoration regularly, which basically de-values any previous effort
spent on this. What was _qs's life time from invention to deprecation?
A bit more than a year?

Besides, most "string theory" changes rely on replacing proper objects by views
(kind of fine, but:) which effectively are mere fat pointers with implicit
lifetime dependencies on other objects, increasing the fragility of code and
raising the maintenance costs (see e.g. 415210 and 510464 in qtbase and fallout)
So, yes, ok to have for the few cases that actually benefit from it, but no,
not a general, universally applicable pattern, let alone something that 
everyone should be bothered with by default.

Regards,
Andre'

PS:

> Surely, the Foundation Team is in the process of creating instructive
> documentation on string theory?

On a sarcastic day I might be tempted to suggest creating an RSS feed for that.
On the other days I'd say that's a two-liner: Recommend QT_RESTRICTED_CAST_FROM_ASCII
at least for non-library code (this includes tests) and be done.