Tisztán az O() jelölés viszont önmagában sokat nem ér gyakorlati szempontból. Pont erről vitatkozunk: egyesek szerint nem lehet hatékony kódot írni anélkül, hogy a használt algoritmusok komplexitását ismernénk.
Majd ugyanő a másik kommentjében ellentmond saját magának: nem elég ismerni a magasszintű O() jelölést, hiszen az "elemi lépés" lehet, hogy nem O(1), hanem O(n) lépésben van implementálva.
Az egész arról szól, hogy igen, hasznos dolog az O() jelölés, de ha a valóságra akarjuk alkalmazni és értelmesen használni, akkor két eset lehetséges:
1. Egészen tranzisztorszintig lemegyünk, és minden szint implementációjának komplexitását ismerve bebizonyítjuk/kiszámoljuk a rendszerünk komplexitását.
2. Megmérjük a keretrendszerünk, a használt algoritmusok komplexitását (azaz nem kell ismernünk az implementációt, mégis tudjuk a tényeket - a mérési eredményről el tudjuk dönteni, hogy O(n) vagy O(n^2) a tényleges komplexitás), majd ezen tények ismeretében cselekszünk: kicseréljük valamelyik alrendszert hatékonyabbra stb.
Hogy hasonló példát mondjak: tegyük fel, hogy Ügyfél úrnak szüksége van az elemi alumínium sűrűségére normál körülmények (hőmérséklet, nyomás) között, 6 tizedesjegy pontossággal.
Két utat választhat:
1. Megbíz egy elméleti fiztikust, aki a kvantummechanikai ismeretek fényében kiszámolja az alumínium sűrűségét 1-2 hónap alatt. Az eredmény totál pontos lesz, megcáfolhatatlan, megbízható.
2. Megkérünk egy kísérleti fizikust, hogy mérje meg. Ő megmondja, hogy ugyan nincs neki éppen dokumentációja (ha lenne, kiolvasná abból), de megméri. 1 hét múlva jön az eredménnyel. Nem teljesen megbízható (hiszen véges sok mérést csinált csak, melyeknek hibája van).
Melyiket választja egy jó mérnök a gyakorlatban?