Nyilván sokféle build van, ahol lehet nyerni időt. A kérdés, hogy megéri-e.
Az elveszett perceket valahol ki is kell tudni termelni.
Sok fejlesztő sok terméknél sajnos elfelejtett optimalizálni (babzsákfejlesztők by hajbazer). Persze ez lehet felülről érkező nyomás ("legyen kész tegnapra"), lehet igénytelenség is. Berántanak 100+ libet, aminek csak egy részét használják, a többi már nem használt a projektben. Tisztelet a kevés kivételnek.
A memory bandwidth monitoring megoldása nem egyszerű, de nem is teljesen lehetetlen. Néhány próbálkozás, megoldás például:
- https://www.intel.com/content/www/us/en/developer/articles/technical/in…
- https://github.com/intel/PerTaskMemBWMonitoring
- https://github.com/LucaCanali/Miscellaneous/blob/master/Spark_Notes/Too…
- https://github.com/intel/pcm
- https://www.amd.com/en/developer/uprof.html
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…
Egyrészt ne keverjük a build és a runtime teljesítményt, másrészt ezért van jobb helyeken ugye UAT/QAS, ahol ez kiderül, mert a tesztelő gépe nem csillagromboló.
Nem keverem. Éltem meg már olyan esetet többször is, hogy UAT/QAS szerint is lassú volt, ezért a ticket már a fejlesztőnél eszkalálódott. Ő meg lezárta annyival, hogy vegyenek csillagrombolót arra a feladatra. Nyilván ez a flegma hozzáállás nem volt vállalható sem befelé, sem az ügyfelek felé.