> Нисколько не умаляя достоинства малых программ, замечу: у вас DLL-ка 72 мега
> - она ПО-ЛЮБОМУ не влезет в кэш!А вовсе нет никакой нужды впихивать 72 мегабайта в кеш. Если какой-то кусок кода выполняется один раз в сутки, то загрузка его в кеш практически никак не повлияет на производительность. Даже если этот кусок в своп будет выпадать за сутки -- это слабо скажется на производительности. В худшем случае будет небольшой лаг. Раз в сутки.
Производительность определяется скоростью работы циклов, и вот тут важно, чтобы код цикла поместился бы в кеш. Если цикл выполняется 10k раз, и на каждой итерации его код загружается в кеш, то это скажется на производительности. Если при этом итерация цикла выполняется за 50 тактов процессора, и ещё десяток тактов тратится на загрузку тела цикла в кеш, то это замедление цикла на 20%.
Если мы код уменьшили на 8% равномерно везде, то все циклы тоже стали на 8% меньше, а это значит, что есть неплохие шансы на то, что какой-то из них не влезал в кеш, а теперь влез.
Ну, это понятно, упрощённая картина: в кеше не только код лежит, ещё и данные, и по сути надо говорить не о том, что код часто грузится, а о том, сколько кеша остаётся свободным для манипуляции с данными после загрузки тела цикла в кеш. С учётом этого я вообще не вижу никакого способа оценить возможные бонусы к производительности в общем случае. Но, тем не менее, пренебрегать этим я бы не стал. 8% объёма -- это круто, это 1/12 часть.
> Да и сами компиляторы
> стали достаточно умные, чтобы генерить более-менее оптимальный код. Я к тому,
> что "выжимка процентов" не стоит своих усилий.
Это если сидеть и вручную писать на ассемблере, тратя на порядок-два больше времени на написание того же кода, тогда действительно не стоит. А если для сокращения кода на 8% надо единожды довести сорцы до совместимости с другим компилятором, и потом придерживаться более строгих гайдлайнов к вновь написанному коду, то в чём проблемы?
А если ещё вспомнить, что подобные преобразования кода положительно сказываются на его качестве, так сам бог велел. Я бы даже сказал, что если код несовместим с другим компилятором, то это самодостаточный повод для того, чтобы заняться совместимостью, не ради производительности или размера, а ради уменьшения количества багов.
> Уменьшить в ДВА раза - да, остальное - от лукавого.
Если раз десять уменьшить время выполнения на 8%, то в сумме выйдет сокращение на 50%.
Если забивать на эти проценты, то в результате получится тормозное нечто. И не только потому, что проценты накопятся, а ещё и потому, что разработчики, не выискивая проценты, потеряют нюх и способность писать быстрый код. Чтобы понимать где и как программа тратит время, надо заниматься оптимизациями. Оптимизации такая штука, что подчастую заранее не знаешь, сколько ты процентов получишь. На скорость выполнения кода влияет очень много чего, и учесть эти факторы все практически невозможно. Очень часто самый простой способ проверить -- переписать код так, как кажется будет лучше, и сравнить. То есть крайне сложно исследовать, где программа проводит время, не совершая попытки оптимизировать по скорости. А не зная, где программа тормозит, невозможно писать не тормозную программу.
Говорить о том, что проценты не важны -- это то же самое, что говорить "производительность не важна".
