( asch | 2020. 11. 10., k – 09:34 )

> Mennyire? Számít, hogy egy alsó középkategóriás gépen egy audiostream 10%? Hogy 1? Hogy fél? Hogy egy tized? Meddig számít? Mennyi plusz cpu fér bele, hogy valamit lehessen generikusan kezelni, és ne kelljen emiatt egy rakás eszközhöz kb ugyanazt leimplementálni kicsit másképp? Mennyi CPU fér bele, hogy kevesebb setupban legyen recsegő hang? Mennyi CPU fér bele, hogy emulálhass featureöket, amiket adott esetben nem támogat valami hardware, és egyébként nem lenne? Meddig éri meg a CPU spórolás miatt miatt sokkal nagyobb, nehezebben karbantartható, olvashatatlanabb, nehezebben portolható, potenciálisan bugosabb, potenciálisan mindenféle hardweren változó minőségű kódot csinálni?

Itt vegyük elő a Hajbazer énünket! Relatíve nem nagy a Linux penetrációja, de összesen mégis nagyon sok gépen fut. Mennyi áramot fogyaszt, menyni CO2 kibocsátással jár egy 5%->10% növekedés? Mennyivel csökken a notebookok üzemideje akksiról? Mivel az a pár százalék CPU is összesen nagyon sok, ezért igenishogy indokolt a spórolás. Ráadásul locsemege infója szerint nem arról van szó, hogy 10-20%-ot lehetne faragni, hanem hogy többszörös a CPU használata, mint muszáj volna.

Ez a karbantarthatóság, portolhatóság gyenge kifogás, mert a jó megoldás sokszor egyáltalán nem bonyolultabb, vagy nehezebben karbantartható. (Ez saját tapasztalat a munkáimból, amikor valamit újraterveztünk eredetileg teljesítmény okokból, akkor sokszor még egyszerűbb is lett a megoldás. De tény, hogy létezik mikor teljesítmény miatt komplexebb lesz a megoldás, ilyenkor mérlegelni kell.) Persze nem néztem a Pipewire implementációját, de gondolom nem kézzel optimalizált X86 assembly az sem, hanem hordozható C. Ugyanis az ilyesmi nagyságrendileg nem mikoroptimalizáláson múlik, hanem architekturális kérdéseken. Abból, hogy egy ember ilyen rövid idő alatt működő programot állított elő, arra következtetek, hogy éppenséggel inkább egyszerű ez a program, mint bonyolult. A mikrooptimalizációnak is létezik még tere, de döntően nem ilyenekről van szó.

A programok teljesítménye fontos, és egy programozó aki ad magára, az számol vele. Nyilván sokmindentől függ, hogy mit mennyire érdemes optimalizálni, de a hangszerver már pont az a kategória amit kellene. A programozó által kiadott program teljesítménye felhasználható a programozó értékelésére. Hiába működik egy program, ha többszörös az erőforráshasználata, mint muszáj lenne, akkor az szar, és az a programozó hibája. Tapasztalatom az, hogy egy 10-100-1000-szeres lassulást simán hanyagságból bele lehet tenni egy programba úgy, hogy még nem is skálázódási a probléma, csak sima lineáris elbaszás. Prototípusnál még belefér, de egy elvileg kész programban ne maradjon ilyen!