Заради това, че процесора работи много по бързо отколкото се прочитат данните от паметта (да не говорим за диска) се получава така, че и да си оптимизирал кода си до дупка той ще се изпълни също толкова бавно колкото и по малко оптимизиран от компилатора защото бавното място е другаде.
Това изказване просто не е вярно.
защото на повечето хора им е все едно дали ще чакат 0.1с или 0.2с т.е. макар да е двойно по бавно е пренебрежимо малко време.
200мс се отличават от 100мс напълно отчетливо. 200мс закъснение се възприема като забавяне и дразни. За да оцениш времевите мащаби, на клавиатурата му 250мс е забавянето за авторепида, а скоростта на повторение е 50 символа в секунда или 20мс. И тия 20мс са интервал, който човек обработва спокойно и отчетливо.
Просто си напиши 2..3 прости примера със паузи и сам ще се убедиш.
Примерно как да изчислиш hex => ASCII с по малко инструкции и памет. Или как да преброиш алгоритмично колко бита са вдигнати. И двете се правят с нечетлив код който само посветени разбират. Колко човека мислиш ще го оценят? Знаеш ли само какъв душевен оргазъм имах като дебъгнах на времето как работи pkzip ... как възстановява hoffman tree само от броя битове на всеки символ в него, как като търси back reference за LZ алгоритъма не сравнява байт по байт ами е работи с хеш таблици и т.н. И това всичкото разписано на асемблер. Навремето така учехме занаята, днес света е друг. Апотеоз на неефективността. Свиквай.
Точно пък NumToStr съм писал именно оптимизирано за размер. И се получава много елегантен и четлив алгоритъм. А относно ZIP алгоритъма, той така е замислен и сегашните библиотеки именно така го правят. Аз съм писал разкомпресиране по RFC-то (с малко помощ от Марк Адлер на stackoverflow) и се получи отлично, компактно и четливо.