En nem hiszek a mikro-optimalizalasban. Inkabb legyen megbizhato a produktum, mint essen, keljen fagyjon ha valaki megvaltoztat valamit.
_UTANA_ lehet optimalizalni a megfelelo szintre.
Ezt igaznak tartom az uzleti termekekre, ahol a befekteto zaros hataridon belul eredmenyt akar, de igaznak a hobbi projektekre ahol az eltoltott szabadido a draga.
Evekig tarott amig elkoptak azok a fejlesztok nalunk, akik ragaszkodtak a raw pointerekhez mert az gyorsabb mint a smart pointer, viszont magam tapasztaltam hogy mennyire "torekeny" az egesz termek, amikor kibovitettem egy enum-ot. Fagyott jopar helyen, mert range checking az mar lassitja a szoftvert - mondtak ok. Hal'Istennek mar kikopott ez a gondolkodas.
"Egy malloc() után nem vizsgálják, hogy megkapta-e a kívánt mennyiségű RAM-ot az alkalmazás"
Altalaban a memoria kezelese az operacios rendszer feladata. (kivetelekrol nem beszelek) Ha nincs eleg memoria, akkor az azt jelenti hogy az egesz rendszer beallt mint a szog, se az operacios rendszernek, sem az alkalmazasoknak nincs memoria. Kb le lehet kapcsolni a gepet kategoria. Az ilyen eseteket profilozassal kell megfogni.
" Nem szükségszerű, hogy ennyi RAM-ot és futásidőt egyenek az alkalmazások"
Kb halad a vilag a managed kod fele a fentebb emlitett okok miatt. Ezert fordul elo hogy egy skype 2 GB-ot eszik :) (desktopon)
"Tehát egész egyszerűen nem is kell ebben egyensúlyra törekedni, mert a probléma másnál keletkezik majd."
Ha nagy a problema, akkor senki sem fogja hasznalni a termeket. Pl egy TC 10 GB-ot hasznalna, akkor senki nem hasznalna.
Tehat beall az az egyensuly. Keszitok belovik az atlag elerheto gepek teljesitmenyet, marmint amin tervezik futtatni - celkozonseg gepeit.
Amugy egy beagyazott, celfeladatra szant MCU-ra mindig is konnyebb - es elvart - az optimalizacio, mert a megoldando feladatok szama nagysagrendekkel kisebb.