бенчмаркинг — количественные показатели (тесты) по использованию библиотек c ++ только для заголовков

Обновить

Это был оригинальный ответ Реального Слава. Его ответ выше (принятый) является его второй попыткой. Я чувствую, что его вторая попытка полностью отвечает на вопрос. — Homer6

Что ж, для сравнения вы можете посмотреть на идею «единства сборки» (ничего общего с графическим движком). По сути, «единство сборки» — это то, где вы включаете все файлы cpp в один файл и компилируете их все как один модуль компиляции. Я думаю, что это должно обеспечить хорошее сравнение, поскольку AFAICT, это эквивалентно тому, чтобы сделать ваш проект только заголовком. Вы будете удивлены 2-м «жуликом», который вы перечислили; весь смысл «построения единства» заключается в снижение время компиляции. Предположительно, единство компилируется быстрее, потому что они:

.. являются способом сокращения накладных расходов на сборку (в частности, открытием и закрытием файлов и сокращением времени компоновки за счет сокращения числа создаваемых объектных файлов) и, как таковые, используются для существенного ускорения времени сборки.

— altdevblogaday

Сравнение времени компиляции (от Вот):

Три основных ссылки на «Единство построения»:

• http://buffered.io/posts/the-magic-of-unity-builds/
• http://cheind.wordpress.com/2009/12/10/reducing-compilation-time-unity-builds/
• http://www.altdevblogaday.com/2011/08/14/the-evils-of-unity-builds/

Я полагаю, вам нужны причины плюсов и минусов.

Плюсы только для заголовка

[…]

3) Это может быть намного быстрее. (Количественный)
Код может быть оптимизирован лучше. Причина в том, что, когда блоки разделены, функция является просто вызовом функции, и поэтому должна быть оставлена ​​таковой. Информация об этом звонке неизвестна, например:

• Изменит ли эта функция память (и, следовательно, наши регистры, отражающие эти переменные / память, будут устаревшими, когда она вернется)?
• Эта функция смотрит на глобальную память (и, следовательно, мы не можем изменить порядок, где мы вызываем функцию)
• и т.п.

Кроме того, если функция внутреннего кода является известно, что может быть целесообразно встроить его (то есть выгрузить его код непосредственно в вызывающую функцию). Встраивание позволяет избежать накладных расходов на вызов функции. Встраивание также позволяет выполнять целый ряд других оптимизаций (например, постоянное распространение; например, мы называем factorial(10)теперь, если компилятор не знает код factorial(), он вынужден оставить это так, но если мы знаем исходный код factorial()мы можем на самом деле переменные переменных в функции и заменить их на 10, и, если нам повезет, мы можем даже получить ответ во время компиляции, вообще ничего не запуская во время выполнения). Другие оптимизации после встраивания включают устранение мертвого кода и (возможно) лучшее предсказание ветвления.

4) Может дать компилятору / компоновщику лучшие возможности для оптимизации (объяснение / количественно, если возможно)

Я думаю, что это следует из (3).

Минусы только для заголовка

1) Раздувает код. (количественно) (как это влияет как на время выполнения, так и на объем памяти)
Только заголовки могут раздуть код несколькими способами, которые я знаю.

Первое — это раздувание шаблона; где компилятор создает ненужные шаблоны типов, которые никогда не используются. Это относится не только к заголовкам, но скорее к шаблонам, и современные компиляторы улучшили это, чтобы сделать его минимальным.

Второй, более очевидный способ — это (чрезмерное) встраивание функций. Если большая функция встроена везде, где она используется, эти вызывающие функции будут увеличиваться в размере. Возможно, это беспокоило размер исполняемых файлов и объем памяти исполняемых образов много лет назад, но пространство на жестком диске и объем памяти выросли, что делает его практически бесполезным. Более важная проблема заключается в том, что этот увеличенный размер функции может испортить кэш команд (так что теперь более крупная функция не помещается в кэш, и теперь кэш должен быть пополнен, поскольку ЦПУ выполняет эту функцию). Давление в регистре будет увеличиваться после встраивания (существует ограничение на количество регистры, оперативная память, с которой процессор может работать напрямую). Это означает, что компилятор должен будет манипулировать регистрами в середине теперь более крупной функции, потому что там слишком много переменных.

2) Более длительное время компиляции. (Количественный)

Что ж, компиляция только с заголовком может логически привести к более длительному времени компиляции по многим причинам (несмотря на производительность «сборок единства»; логика не обязательно является реальной, где задействованы другие факторы). Одной из причин может быть то, что если весь проект только для заголовков, мы теряем инкрементные сборки. Это означает, что любое изменение в любой части проекта означает, что весь проект должен быть перестроен, в то время как с отдельными модулями компиляции изменения в одном cpp просто означают, что объектный файл должен быть перестроен, а проект перекомпонован.

По моему (неподтвержденному) опыту, это большой успех. Только заголовки в некоторых особых случаях значительно повышают производительность, но с точки зрения производительности это обычно не стоит. Когда вы начинаете получать большую кодовую базу, время компиляции с нуля может занять> 10 минут каждый раз. Перекомпиляция на крошечном изменении начинает становиться утомительной. Вы не знаете, сколько раз я забыл «;» и мне пришлось ждать 5 минут, чтобы услышать об этом, только чтобы вернуться и исправить это, а затем подождать еще 5 минут, чтобы найти что-то еще, что я только что представил, исправив «;».

Производительность отличная, производительность намного лучше; это потратит большую часть вашего времени и лишит мотивации / отвлечет вас от вашей цели программирования.

Редактировать: Я должен отметить, что межпроцедурная оптимизация (смотрите также оптимизация времени соединения, а также оптимизация всей программы) пытается реализовать преимущества оптимизации «единства построения». Реализация этого все еще немного шатка в большинстве компиляторов AFAIK, но в конечном итоге это может преодолеть преимущества производительности.

Я надеюсь, что это не слишком похоже на то, что сказал Realz.

Размер исполняемого файла (/ объекта): (исполняемый файл 0% / объект увеличивается до 50% только в заголовке)

Я бы предположил, что определенные функции в заголовочном файле будут скопированы в каждый объект. Когда дело доходит до генерации исполняемого файла, я бы сказал, что довольно просто вырезать дублирующиеся функции (понятия не имею, какие компоновщики делают / не делают этого, я полагаю, большинство это делают), поэтому (вероятно) никакой реальной разницы в размер исполняемого файла, но хорошо в размер объекта. Разница должна в значительной степени зависеть от того, сколько кода на самом деле находится в заголовках по сравнению с остальной частью проекта. Не то, чтобы размер объекта действительно имел значение в наши дни, за исключением времени ссылки.

Время выполнения: (1%)

Я бы сказал, что в основном идентично (адрес функции — это адрес функции), за исключением встроенных функций. Я ожидаю, что встроенные функции будут иметь различие в вашей средней программе менее чем на 1%, потому что вызовы функций имеют некоторые накладные расходы, но это ничто по сравнению с накладными расходами на фактические действия с программой.

Объем памяти: (0%)

Те же вещи в исполняемом файле = тот же объем памяти (во время выполнения), при условии, что компоновщик удаляет дублирующиеся функции. Если дублирующиеся функции не вырезаны, это может иметь большое значение.

Время компиляции (как для всего проекта, так и путем изменения одного файла): (на целых до 50% быстрее для одного, одного на 99% быстрее для не только заголовка)

Огромная разница. Изменение чего-либо в заголовочном файле вызывает перекомпиляцию всего, что включает его, в то время как изменения в файле cpp просто требуют пересоздания этого объекта и повторной ссылки. И на 50% медленнее для полной компиляции только для библиотек с заголовками. Тем не менее, с предварительной компиляцией заголовков или сборок Unity полная компиляция с библиотеками только для заголовков, вероятно, будет быстрее, но одно изменение, требующее перекомпиляции большого количества файлов, является огромным недостатком, и я бы сказал, что это того не стоит , Полные перекомпиляции часто не нужны. Кроме того, вы можете включить что-то в файл cpp, но не в его заголовочный файл (это может часто случаться), поэтому в правильно спроектированной программе (древовидная структура зависимостей / модульность) при изменении объявления функции или чего-либо (всегда требуется изменения в файл заголовка), только заголовок может привести к перекомпиляции многих вещей, но с не только заголовком вы можете значительно ограничить это.

Время соединения: (до 50% быстрее только для заголовков)

Объекты, вероятно, больше, поэтому их обработка займет больше времени. Вероятно, линейно пропорционально тому, насколько больше файлы. Из моего ограниченного опыта в больших проектах (где время компиляции + ссылки достаточно велико, чтобы действительно иметь значение), время линковки практически ничтожно по сравнению со временем компиляции (если вы не будете вносить небольшие изменения и строить, тогда я ожидаю, что вы почувствуете это что, я полагаю, может случиться часто).