Re: [Development] Using string literals in autotests

2024-04-02 Thread Edward Welbourne via Development
Andre' (28 March 2024 15:22) asked:
> What was _qs's life time from invention to deprecation?
> A bit more than a year?

Yes: _qs was added in 6.2 (2021-03-04) and, in 6.4 (2022-03-21, when _s
was added), declared deprecated from 6.8.

Mistakes get made.  We fix them as soon as we reasonably can after
recognising they've been made.  I very much doubt that _s and its peers
will suffer a similar fate.  They've already lasted twice as long as what
they replaced.

Friedemann Kleint (Thu, Mar 28, 2024 at 12:14:35PM +0100) had asked:
>> Surely, the Foundation Team is in the process of creating instructive
>> documentation on string theory?

https://bugreports.qt.io/browse/QTBUG-77020
Hopefully soon.

Andre' answered:
> 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.

That sounds like a fairly good TL;DR summary of one sane policy.
A QT_RESTRICTED_CAST_FROM_ASCII how-to would improve it.

While I'd generally encourage folk changing code to, as long as they're
confident they know what's better, modernise string usage in the changed
code, it seems unreasonable to require those fixing bugs to the choice
of string representation to make unrelated changes to fix such
preexisting details.  Suggest it as a possibly worth-while drive-by, to
be sure, but it shouldn't block their bug-fixes or feature development.

I'm afraid any energy savings per run of CI, that could be made by
mildly improving string usage, have to be offset against at least the
(energy costs of the) extra CI runs
* that must be made to integrate such modernisation changes, and
* that'll be forced when other folks' subsequent changes follow the
  modern form after a modernisation, are picked back to before it and
  then fail to build until the author fixes them to be compatible with
  the older code-base.

While that won't stop me modernising as part of cleaning up existing
code, when I feel moved to do that, I'd encourage doing any such
clean-up as a single comprehensive revision (of at least one whole test)
rather than piecemeal, so as to reduce the number of extra CI runs due
to at least the first of these.  Of course, changes made as part of
other work avoid those extra CI runs, so provide a path towards
incremental improvement, when they fit naturally for those doing that
other work.

Eddy.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] Using string literals in autotests

2024-03-28 Thread 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.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] Using string literals in autotests

2024-03-28 Thread Giuseppe D'Angelo via Development

Il 28/03/24 12:14, Friedemann Kleint via Development ha scritto:

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.


Diminishing CI run time and saving energy is certainly an excellent 
goal, but this is starting from the wrong end. A qWait(100), or a few 
extra memory allocations, or a wrong algorithm will easily squander any 
saving that you could gain when optimally comparing strings. You'd need 
to micro-optimize so much that it simply isn't worth the effort.




Here's another hot take. Consider:

* A(X) = how much energy is wasted when a random CI node goes bust for X 
hours -- and that makes integrations fail on all the CI -- although the 
other nodes did build+test the code. (This very morning: WASM is 
blocking qtbase/dev integrations)


* B = how much time/energy you save, per CI integration, by 
micro-optimizing every string construction/comparison




How much work is necessary to achieve B? And then, how many CI runs are 
necessary to offset the waste that e.g. 24h of CI downtime cause?


I feel we're easily into the man-years of effort (maybe this can be 
partially tooled, but then, the tooling needs to constantly chase up 
changes in QtCore), and dozens of thousands of CI runs. Which makes the 
effort pointless: it takes years to get thousands of CI runs (qtbase 
integrations take ~2h?), during which the CI will go bust *again*, 
squandering all your savings.



My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence



smime.p7s
Description: Firma crittografica S/MIME
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] Using string literals in autotests

2024-03-28 Thread Friedemann Kleint via Development

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.


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.


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


Regards, Friedemann

--

Friedemann Kleint
The Qt Company GmbH

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] Using string literals in autotests

2024-03-28 Thread Giuseppe D'Angelo via Development

On 28/03/2024 10:36, Axel Spoerl via Development wrote:


Since _L1 usage is massive in corelib, I wonder whether there is a 
standard that everyone can apply when writing or reviewing autotests. If 
it exists and I have overlooked it, please forgive my negligence and 
point me to it.


  *
What is the recommended way to construct a string in autotests?
  *
Where to place "using namespace"?
  *
Shall string constructions be fixed as a drive-by?


IMHO, clarifying these questions generally helps and expedites code reviews.
See https://codereview.qt-project.org/c/qt/qtbase/+/551645 
 as a recent example.


TL;DR: leave it alone.

I don't think there is any specific guidance here. Autotests usually 
follow much more "relaxed" rules wrt the rest of Qt; APIs that are 
usually disabled or trigger deprecation warnings if called by library 
code "just work" when called from autotests.


IMHO, test code should be easy to write (we want people to write MORE 
test cases!) even if, pedantically, the APIs used in a test's source 
code aren't the Absolute Best™ available at the moment.


Therefore it becomes a matter of style, and of code evolution. You'll 
find a mix of styles (sometimes even in the same file) simply because 
some code predates the introduction of certain facilities (like the _L1 
user-defined literal). Again I don't think there's anything wrong with 
it, *especially* in test code, and spending time to port these usages 
sounds counter-productive to me.


Even more specifically: 1) "how do we do strings in Qt" has been 
constantly changing (possibly in every single minor release of Qt), 
because we've been adding more and more features; and 2) strings are 
obviously used *everywhere*. Therefore, it's very easy to find code that 
doesn't use "the latest and the greatest" incantation to accomplish a 
given task. On top of this, add the massive mental burden of remembering 
which one even *is* the latest and the greatest.


And, in your case: you can just write QCOMPARE(str, "foo"), as there's a 
suitable qCompare overload.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


[Development] Using string literals in autotests

2024-03-28 Thread Axel Spoerl via Development
Hi,

is there any documentation, blog post, wiki page, other source or guideline 
about usage of string literals in autotests?

More specifically:

The line
QString ("I love QLatin1StringView");

...triggers 'QString' is deprecated: Use fromUtf8, QStringLiteral, or 
QLatin1StringView. QString has been explicitly marked deprecated here'

in qwindow.cpp, but not in tst_qwindow.cpp.

In gui autotests, only tst_QStandardItemModel uses the _L1 macro, in widgets 
only tst_QComboBox. "using namespace Qt::StringLiterals" can be found at the 
beginning of a test class, as well as at the beginning of a test function.
>From what I see, most test functions actually construct QString with a const 
>char*. Some use QStringLiteral locally, others use QLatin1StringView.

Since _L1 usage is massive in corelib, I wonder whether there is a standard 
that everyone can apply when writing or reviewing autotests. If it exists and I 
have overlooked it, please forgive my negligence and point me to it.


  *
What is the recommended way to construct a string in autotests?
  *
Where to place "using namespace"?
  *
Shall string constructions be fixed as a drive-by?

IMHO, clarifying these questions generally helps and expedites code reviews.
See 
https://codereview.qt-project.org/c/qt/qtbase/+/551645
 as a recent example.

Thanks, kind regards and happy Easter
Axel
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development