Чем плохи большие размеры исполняемых файлов?

#cpp #оптимизация #сборка #компоновщик

Уже не раз видел ответы людей по типу: 


  -О3 генерирует быстрый, но раздутый исполняемый файл





  LTO помогает этот раздутый код уменьшить





  Шаблоны С++ приводят к распуханию исполняемого файла, это плохо


или 


  Используй компоновщик gold вместо gnu-ld, он собирает меньший по размеру исполняемый
файл... 


Каждая из приведенных фраз это, конечно, целая дискуссия, но у всех одна цель - уменьшить
размер бинарного файла. 

Объясните, пожалуйста, почему так важно иметь как можно меньший по размеру бинарный
файл? Связано ли это со скоростью загрузки приложения, кэша инструкций процессора,
или еще с чем-то?
    

Ответы

Ответ 1

Для начала предлагаю отвлечься от слова "исполняемый" и рассмотреть просто файл.
Что значит большой размер? Файл потребует больше места для хранения, он дольше будет
копироваться или как-то иначе обрабатываться, когда речь идет об обработке его содержимого,
а не просто имени или даты создания. В таких случаях часто прибегают к механизмам дополнительного
сжатия информации, проще говоря, архивированию. Это уменьшит размер и время копирования,
но для последующей обработки, вероятнее всего, придется выполнить распаковку, что может
в итоге даже увеличить время обработки по сравнению с несжатым файлом.

Теперь, чем отличается исполняемый файл от обычного? Он так или иначе содержит код,
набор инструкций, которые должен выполнить (обработать) процессор. Понятно, что размер
программы зависит от предоставляемого функционала, и наращивание логики приведет к
увеличению размера. В большинстве случаев это не является проблемой, так как диски
становятся всё больше, память и процессоры быстрее, а архитектурные решения опираются
на декомпозицию: разделение кода на модули/библиотеки и подгрузку кода по мере необходимости.
Но в некоторых ситуациях, например, в микроконтроллерах ресурсы серьезно ограничены
и там идет борьба за размер, и использование разных техник оптимизации. 

Кстати, для исполняемых файлов тоже существуют архиваторы, один из них, это UPX.


Ответ 2

-О3 генерирует быстрый, но раздутый исполняемый файл


По нынешним временам для большинства задач скорость более критична чем размер файла.
Если код быстрый (все инлайн подстановки выполнены, многие циклы развернуты, все инварианты
вынесены из циклов) то больше ничего от кода и не надо. Ребята, которые пишут оптимизаторы,
не зря едят свои гамбургеры. Если нужен БЫСТРЫЙ код, то следует применять оптимизацию.


  шаблоны c++ приводят к распуханию исполняемого файла


Это утверждение более чем спорно. Если шаблоны нужны в данной задаче, то они никак
не увеличивают код по сравнению с ручным переписыванием классов с незначительными изменениями.
В любом случае инстанцирование шаблона в С++ вполне прозрачно и всегда понятно, во
что компилятор развернет шаблон.

UPD1: Для микроконтроллеров теоретически есть проблема размера бинарника но и там
память дешевле чем скорость даже более чем на десктопах и серверах. Так что если на
микроконтроллере бинарник не влезает в память, то это показатель плохого дизайна системы.
Всегда проще и дешевле поставить лишний чип памяти, а вот добавить лишних терафлопсов
это уже совсем другие деньги.