Будет ли хит производительности при включении неиспользуемых файлов заголовков в C / C++?
у меня есть проект, где каждый файл C/C++ использует кучу заголовочных файлов. Но около 70-80% заголовочных файлов, которые использует каждый файл C/C++, одинаковы. Поэтому, чтобы сделать мой код более читаемым, я планирую включить все заголовки, которые мне понадобятся в проекте, в один файл заголовка say common_headers.h
и включить это во все мои файлы C / C++, как это:
#include "common_headers.h"
теперь это будет включать все необходимые заголовки, но и несколько дополнительных заголовков, которые не будут использованы физическим лицом файл. Я хочу знать, если делать это таким образом, это случайно не повлияет на производительность во время выполнения?
Я в порядке с дополнительной задержкой в несколько миллисекунд для компиляции кода, но я хочу знать, повлияет ли это на мою производительность выполнения?
описание заголовки:
- большинство из них являются стандартными заголовками C/C++.
- пользовательские заголовки имеют встроенные функции шаблона в них .
- отсутствие статических функций внутри пользователь определенные заголовки.
Это мой компилятор: g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)
4 ответов
компиляция:
если что - то включено, то оно должно анализироваться, даже если оно никогда не будет скомпилировано и связано, поэтому время компиляции наверняка увеличится -не включать неиспользуемые заголовки.
среда:
уже упоминалось @DonReba, что неиспользуемые заголовки могут включать некоторые pragma
директивы, которые могут изменить полученный исполняемый файл, но обычно это не будет случай.
большинство неиспользуемых функций и declaraions будут оптимизированы, за исключением некоторых конкретных случаях - оптимизируются ли неиспользуемые функции?. Результирующий exe может стать немного больше, но эти функции и переменные не будут использоваться, поэтому общее воздействие будет минимальным. - - тем не менее, не включайте неиспользуемые заголовки.
резюме:
Если вы можете изменить исходный код не содержит ничего ненужного - изменить его.
Personnaly я предпочитаю иметь автономные модули (заголовки), которые включают все, что им нужно - не более и не менее. Такие модули могут быть добавлены и удалены без оглядки и возможности того, что какая-то ненужная зависимость осталась. Они все еще не панацея, но в сочетании с внимательностью и некоторым анализом кода они будут держать вашу программу свободной от заголовков мертвого веса.
EDIT:
Precompiled заголовки:
предварительно скомпилированные заголовки используются для сокращения времени компиляции часто используемых, но редко изменяемых заголовков (системных заголовков, огромных заголовков проектов), поэтому, если эти неиспользуемые заголовки включены в предварительно скомпилированный заголовок, то эффект времени компиляции во время последующих компиляций будет сведен к минимуму. Тем не менее, все проблемы во время выполнения, независимо от того, насколько они малы, остаются такими же, как для простого заголовка.
короткий ответ на заданный вопрос: нет.
ответ:
больше заголовков означает незначительно больше шансов появления какой-либо проблемы, которая может проявляться как проблема производительности, но это действительно не проблема.
многие считают, что это плохой стиль, чтобы сделать, как вы планируете, но есть и те, которые считают это приемлемым.
одна из ключевых причин избежать этого стиля заключается в том, что он облегчит получение кругового зависимости.
Я бы не рекомендовал его из-за проблемы времени компиляции, где у меня нет предварительно скомпилированных заголовков.
зависит от компилятора. Сегодня большинство компиляторов умны и используют предварительно скомпилированные заголовки для повышения производительности. Я использую GCC
компилятор, поддерживающий предварительно скомпилированный заголовок и AFAIK, не влияет на производительность.
возможно, что включение дополнительного заголовка приведет к другому коду выполнения из-за переопределения директивы препроцессора. Но это была бы ненормальная ситуация.
Visual C++, GCC и Clang поддерживают предварительно скомпилированные заголовки для улучшения времени компиляции для таких случаев использования, как ваш.