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

Attachment: smime.p7s
Description: Firma crittografica S/MIME

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

Reply via email to