Ha egy kliens egy weblapot használ, a teljes időnek illetve a teljes számítási kapacitásnak vajon mekkora része esik az OpenSSL-re?
Nem mértem ki, mivel nem fejlesztettem ilyesmit, de feltételezem, hogy kevés.
Pl. arra számítanék, hogy a UI renderelés, illetve a másik oldalon az adatbázisból az adatok előkeresése illetve magának az adatnak a hálózaton áttolása több nagyságrenddel lassabb, mint a titkosítás szőröstül bőröstül.
De ettől függetlenül, ha most konkrétan az OpenSSL-t akarnánk gyorsabbá tenni, szerinted valaki kimérte azt, hogy az adott függvény a lassú, és éppen a segédváltozó miatt, vagy egyszerűen a programozó eldöntötte, hogy így írja meg, mert szerinte így gyorsabb?
Nem tudom a választ, de az a sejtésem, hogy a második.
Volt olyan kollégám, aki mindenféle trükkökkel írt C-ben kódot elsőre, merthogy úgy gyorsabb lesz. Aztán amikor megnéztük, kiderült, hogy a gcc pontosan ugyanarra az assembly programra fordította le, mint az agyontrükközetlen változatot.
Na ez az, ami szerintem nagyon rossz megközelítés.
Egyébként a kérdésedre válaszolva, hogy mi az, ahol szerintem szempont a sebesség:
az én múltamban ezek fordultak elő:
- játék - adott hw követelményből kihozni a legjobbat. Férjen bele még több pont, még több 3D effekt és számolás, de ne essen az FPS x alá adott procival és videokártyával; a video lehessen még nagyobb felbontású és hosszabb de a 4x sebességű CD-ről azért le lehessen játszani; az AI tudjon tovább előre gondolkodni, több esetet megvizsgálni, hosszabb utat keresni anélkül, hogy a neki engedélyezett időnél többet használna.
- real time rendszer, hálózat minőség mérése, adatfeldolgozás - minél több mérőeszköz adatáramát tudja feldolgozni egy számítógép
- adatok tárolása adatbázisban (fájl betöltés és eltárolás legyen meg 15s alatt, pl. amikor alapból 30 percnél indult az első változattal, másik esetben néhány fájl betöltése max. 2 óra alatt, miközben a régi rendszernek 24 óra nem volt elég).
- adatok visszakeresése adatbázisból (pár tíz millió adatrekord, egy időben 1000 kérés, 1 másodperc alatti válaszidő weblap rendeléssel együtt). Aztán folyamatosan jönnek az új kérések, bonyolítva a lekérdezést, de az NFR nem változik.
Ezekben az esetekben mindenhol jól azonosítható volt egy konkrét szűk keresztmetszet, amit javítani kellett.
Hiába javítottunk volna más rendszerkomponenst, vagy csak még több félig feldolgozott adat gyűlt volna fel az igazi problémás elem előtt, vagy amikor végre valami kijött, az gyorsabban ért volna el a cső végére - de az idő még nagyobb részében várt volna az a feldolgozó sor.