KOJA: Myslim ze ano. Je to videt vsude kolem (me :-) To si ale nutne neprotireci s tim
<i>ze na hromadu problemu staci rozumny navrh na urovni architektury a (pardon) "mikrooptimalizace" nejsou potreba</i>. Samozrejme, pokud mas O(n^3) algoritmus a existuje O(nlogn), pak nema cenu "mikrooptimalizovat" ten n^3. O tom zadna.
Zalezi na tom co delas. Pokud delas nejakou aplikaci, rekneme nejaky IS nebo tak, pak asi opravdu jedine, co ma smysl je pouziti dobrych algoritmu a rozumne cacheovani.
Pokud ale delas vis low-level - zakladni knihovny, runtime, prekladace - pak je dost citit jestli neco udelas na ~1 cachemiss nebo na ~10 cachemiss, prestoze slozitost obou je O(1), rekneme. Nebo je dost rozdil, jestli
napises
if (error) {
handle_error();
return;
} else {
...
}
nebo
if (!error) {
....
return;
} else {
handle_error();
}
pripadne
if (error) goto handle_error;
fixed: ...
return
fix_error();
goto fixed;
pokud je to low-level kod, provadi se opravdu casto a muze to bolet (vlastni zkusenost :-)
On i ten
REDGUYem vysmivany benchmark ukaze zajimave veci - ono to neni tak ze <i>podstate testuje jednu jedinou funkci v dost trivialnich podminkach<i>. On spis testuje, jak dobry je optimalizator a jak se chova - obzvlaste na jit systemech se spekulativnim inlinovanim (dokaze tu funkci nainlinovat? Kdy to udela? Od kdy se vyplati zpomaleni zpusobene rekompilaci, OSR, a naslednym restartem? Kdy deoptimalizuje?). Kdyby tyhle veci nemeli velky vyznam, nedelalo by se to - je to _dost_ prace to odladit :-)