Вот несколько причин:

1) Грамматика C++ сложнее, чем C# или Java, и требует больше времени для анализа.

2) (что более важно) компилятор C++ создает машинный код и выполняет все оптимизации во время компиляции. C# и Java идут половиной пути и оставляют эти шаги JIT.

C++ скомпилирован в машинный код. Итак, у вас есть препроцессор, компилятор, оптимизатор и, наконец, ассемблер, и все они должны работать.

Java и C# компилируются в байт-код / ​​IL, а виртуальная машина Java / .NET Framework выполняется (или JIT-компиляция в машинный код) перед выполнением.

Python - это интерпретируемый язык, который также компилируется в байт-код.

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

Другая причина - использование препроцессора C для поиска объявлений. Даже с защитой заголовков .h все равно придется анализировать снова и снова, каждый раз, когда они включаются. Некоторые компиляторы поддерживают предварительно скомпилированные заголовки, которые могут помочь в этом, но они не всегда используются.

См. Также: C++ Часто задаваемые ответы

Скомпилированный язык всегда требует больших начальных накладных расходов, чем интерпретируемый язык. Вдобавок, возможно, вы не очень хорошо структурировали свой код C++. Например:

#include "BigClass.h"

class SmallClass
{
   BigClass m_bigClass;
}

Компилируется намного медленнее, чем:

class BigClass;

class SmallClass
{
   BigClass* m_bigClass;
}

Некоторые причины

Заголовочные файлы

Каждая единица компиляции требует, чтобы были (1) загружены и (2) скомпилированы сотни или даже тысячи заголовков. Каждый из них обычно должен быть перекомпилирован для каждой единицы компиляции, потому что препроцессор гарантирует, что результат компиляции заголовка мощь будет различаться для каждой единицы компиляции. (Макрос может быть определен в одном модуле компиляции, который изменяет содержимое заголовка).

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

Связывание

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

Парсинг

Синтаксис чрезвычайно сложен для анализа, сильно зависит от контекста и очень трудно устранить неоднозначность. На это уходит много времени.

Шаблоны

В C# List<T> - единственный компилируемый тип, независимо от того, сколько экземпляров List у вас есть в вашей программе. В C++ vector<int> - это полностью отдельный тип от vector<float>, и каждый из них должен быть скомпилирован отдельно.

Добавьте к этому, что шаблоны составляют полный по Тьюрингу «подъязык», который компилятор должен интерпретировать, и это может стать до смешного сложным. Даже относительно простой код метапрограммирования шаблонов может определять рекурсивные шаблоны, которые создают десятки и десятки экземпляров шаблонов. Шаблоны также могут приводить к очень сложным типам с смехотворно длинными именами, что добавляет компоновщику много дополнительной работы. (Приходится сравнивать множество имен символов, и если эти имена могут вырасти до многих тысяч символов, это может стать довольно дорогостоящим).

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

Оптимизация

C++ допускает некоторые очень существенные оптимизации. C# или Java не позволяют полностью исключить классы (они должны присутствовать для целей отражения), но даже простая метапрограмма шаблона C++ может легко генерировать десятки или сотни классов, все они встраиваются и снова удаляются на этапе оптимизации.

Более того, программа на C++ должна быть полностью оптимизирована компилятором. Программа на C# может полагаться на JIT-компилятор для выполнения дополнительных оптимизаций во время загрузки, У C++ нет таких «вторых шансов». То, что генерирует компилятор, оптимизировано настолько, насколько это возможно.

Машина

C++ компилируется в машинный код, который может быть несколько сложнее, чем использование байт-кода Java или .NET (особенно в случае x86). (Это упомянуто для полноты только потому, что это было упомянуто в комментариях и тому подобном. На практике этот шаг вряд ли займет больше, чем крошечную долю от общего времени компиляции).

Заключение

Большинство из этих факторов разделяются кодом C, который на самом деле компилируется довольно эффективно. Этап синтаксического анализа намного сложнее в C++ и может занять значительно больше времени, но, вероятно, основным нарушителем являются шаблоны. Они полезны и делают C++ гораздо более мощным языком, но они также сказываются на скорости компиляции.

Замедление не обязательно одинаково для любого компилятора.

Я не использовал Delphi или Kylix, но еще во времена MS-DOS программа Turbo Pascal компилировалась почти мгновенно, в то время как эквивалентная программа Turbo C++ просто сканировала.

Двумя основными отличиями были очень сильная модульная система и синтаксис, допускавший однопроходную компиляцию.

Конечно, возможно, что скорость компиляции просто не была приоритетом для разработчиков компилятора C++, но есть также некоторые присущие синтаксису C / C++ сложности, которые затрудняют его обработку. (Я не специалист по C, но Уолтер Брайт является экспертом, и после создания различных коммерческих компиляторов C / C++ он создал язык D. Одно из его изменений должен был обеспечить соблюдение контекстно-свободной грамматики, чтобы облегчить синтаксический анализ языка.)

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

Парсинг и генерация кода на самом деле довольно быстрые. Настоящая проблема - это открытие и закрытие файлов. Помните, что даже с включенной защитой компилятор все равно откроет файл .H и прочитает каждую строку (а затем проигнорирует ее).

Однажды друг (когда ему было скучно на работе) взял приложение своей компании и поместил все - все исходные файлы и файлы заголовков - в один большой файл. Время компиляции упало с 3 часов до 7 минут.

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

Самые большие проблемы:

1) Бесконечный повторный анализ заголовка. Уже упоминалось. Меры по устранению (например, #pragma once) обычно работают только для каждой единицы компиляции, а не для каждой сборки.

2) Тот факт, что инструментальная цепочка часто разделена на несколько двоичных файлов (make, препроцессор, компилятор, ассемблер, архиватор, impdef, компоновщик и dlltool в крайних случаях), которые все должны повторно инициализировать и перезагружать все состояние все время для каждого вызова ( компилятор, ассемблер) или каждую пару файлов (архиватор, компоновщик и dlltool).

См. Также это обсуждение на comp.compilers: http://compilers.iecc.com/comparch/article/03-11-078, особенно это:

http://compilers.iecc.com/comparch/article/02-07-128

Обратите внимание, что Джон, модератор comp.compilers, похоже, согласен, и это означает, что должно быть возможно достичь аналогичных скоростей и для C, если полностью интегрировать инструментальную цепочку и реализовать предварительно скомпилированные заголовки. Многие коммерческие компиляторы C в той или иной степени делают это.

Обратите внимание, что Unix-модель выделения всего в отдельный двоичный файл - это своего рода модель наихудшего случая для Windows (с ее медленным созданием процесса). Это очень заметно при сравнении времени сборки GCC между Windows и * nix, особенно если система make / configure также вызывает некоторые программы только для получения информации.

Большинство ответов немного неясны при упоминании того, что C# всегда будет работать медленнее из-за затрат на выполнение действий, которые в C++ выполняются только один раз во время компиляции, эта стоимость производительности также влияет из-за зависимостей во время выполнения (больше вещей для загрузки, чтобы иметь возможность для запуска), не говоря уже о том, что программы на C# всегда будут иметь больший объем памяти, что приводит к тому, что производительность более тесно связана с возможностями доступного оборудования. То же самое верно и для других языков, которые интерпретируются или зависят от виртуальной машины.

Простой способ сократить время компиляции в больших проектах C++ - создать включаемый файл * .cpp, который включает все файлы cpp в вашем проекте, и скомпилировать его. Это сводит проблему взрыва заголовка до одного раза. Преимущество этого заключается в том, что ошибки компиляции по-прежнему будут ссылаться на правильный файл.

Например, предположим, что у вас есть a.cpp, b.cpp и c.cpp .. создайте файл: everything.cpp:

#include "a.cpp"
#include "b.cpp"
#include "c.cpp"

Затем скомпилируйте проект, просто сделав all.cpp

Сборка C / C++: что происходит на самом деле и почему это занимает так много времени

Относительно большая часть времени разработки программного обеспечения тратится не на написание, запуск, отладку или даже разработку кода, а на ожидание завершения компиляции. Чтобы ускорить процесс, мы сначала должны понять, что происходит при компиляции программного обеспечения C / C++. Шаги примерно следующие:

• Конфигурация
• Запуск инструмента сборки
• Проверка зависимости
• Компиляция
• Связывание

Теперь мы рассмотрим каждый шаг более подробно, уделяя особое внимание тому, как их можно сделать быстрее.

Конфигурация

Это первый шаг при начале сборки. Обычно означает запуск скрипта настройки или CMake, Gyp, SCons или другого инструмента. Для очень больших скриптов настройки на основе Autotools это может занять от одной секунды до нескольких минут.

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

Запуск инструмента сборки

Вот что происходит, когда вы запускаете make или щелкаете значок сборки в IDE (который обычно является псевдонимом для make). Бинарный файл инструмента сборки запускается и считывает свои файлы конфигурации, а также конфигурацию сборки, которые обычно являются одним и тем же.

В зависимости от сложности сборки и размера это может занять от долей секунды до нескольких секунд. Само по себе это было бы не так уж и плохо. К сожалению, большинство систем сборки на основе make вызывают вызов make от десятков до сотен раз для каждой отдельной сборки. Обычно это вызвано рекурсивным использованием make (что плохо).

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

Проверка зависимости

После того, как инструмент сборки прочитал свою конфигурацию, он должен определить, какие файлы были изменены, а какие нужно перекомпилировать. Файлы конфигурации содержат ориентированный ациклический граф, описывающий зависимости сборки. Этот график обычно строится на этапе настройки. Время запуска инструмента сборки и сканер зависимостей запускаются при каждой сборке. Их объединенная среда выполнения определяет нижнюю границу цикла редактирования-компиляции-отладки. Для небольших проектов это время обычно составляет несколько секунд или около того. Это терпимо. Есть альтернативы Make. Самый быстрый из них - Ninja, созданный инженерами Google для Chromium. Если вы используете CMake или Gyp для сборки, просто переключитесь на их серверную часть Ninja. Вам не нужно ничего менять в самих файлах сборки, просто наслаждайтесь увеличением скорости. Однако Ninja не входит в состав большинства дистрибутивов, поэтому вам, возможно, придется установить его самостоятельно.

Компиляция

На этом этапе мы, наконец, вызываем компилятор. Срезая углы, вот примерные шаги.

• Слияние включает
• Разбор кода
• Генерация / оптимизация кода

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

Их использование требует небольшого количества смазки, но польза неоспорима. Более быстрое время сборки приводит к более счастливым разработчикам, большей гибкости и, в конечном итоге, к лучшему коду.

Я могу подумать о двух проблемах, которые могут повлиять на скорость компиляции ваших программ на C++.

ВОЗМОЖНЫЙ ВОПРОС №1 - СОСТАВЛЕНИЕ ЗАГОЛОВКИ: (Это может быть или не было уже рассмотрено в другом ответе или комментарии.) Microsoft Visual C++ (A.K.A. VC++) поддерживает предварительно скомпилированные заголовки, что я настоятельно рекомендую. Когда вы создаете новый проект и выбираете тип создаваемой программы, на вашем экране должно появиться окно мастера установки. Если вы нажмете кнопку «Далее>» внизу окна, вы попадете на страницу с несколькими списками функций; убедитесь, что установлен флажок рядом с параметром «Предварительно скомпилированный заголовок». (ПРИМЕЧАНИЕ. Я имел опыт работы с консольными приложениями Win32 на C++, но это может быть не так со всеми видами программ на C++.)

ВОЗМОЖНЫЙ ВОПРОС № 2 - МЕСТО, СОБИРАЮЩЕЕ: Этим летом я прошел курс программирования, и нам пришлось хранить все наши проекты на флеш-накопителях объемом 8 ГБ, поскольку компьютеры в лаборатории, которые мы использовали, стирались каждую ночь в полночь, что могло стереть всю нашу работу. Если вы компилируете на внешнее запоминающее устройство ради переносимости / безопасности / и т. д., Для компиляции вашей программы может потребоваться время очень долго (даже с предварительно скомпилированными заголовками, о которых я упоминал выше), особенно если это довольно большая программа. . Мой совет в этом случае - создавать и компилировать программы на жестком диске компьютера, который вы используете, и всякий раз, когда вы хотите / должны прекратить работу над своим проектом (проектами) по какой-либо причине, перенесите их на внешний запоминающее устройство, а затем щелкните значок «Безопасное извлечение оборудования и извлечение носителя», который должен появиться в виде небольшой флэш-накопителя за небольшим зеленым кружком с белой галочкой, чтобы отключить его.

Я надеюсь, это поможет вам; дайте мне знать, если это произойдет! :)

В больших объектно-ориентированных проектах существенная причина заключается в том, что C++ затрудняет ограничение зависимостей.

Частные функции должны быть перечислены в общедоступном заголовке соответствующего класса, что делает зависимости более транзитивными (заразительными), чем они должны быть:

// Ugly private dependencies
#include <map>
#include <list>
#include <chrono>
#include <stdio.h>
#include <Internal/SecretArea.h>
#include <ThirdParty/GodObjectFactory.h>

class ICantHelpButShowMyPrivatePartsSorry
{
public:
    int facade(int);

private:
    std::map<int, int> implementation_detail_1(std::list<int>);
    std::chrono::years implementation_detail_2(FILE*);
    Intern::SecretArea implementation_detail_3(const GodObjectFactory&);
};

Если этот шаблон блаженно повторяется в деревьях зависимостей заголовков, это имеет тенденцию создавать несколько «божественных заголовков», которые косвенно включают большие части всех заголовков в проекте. Они такие же всезнающие, как объекты бога, за исключением того, что это не очевидно, пока вы не нарисуете их деревья включения.

Это увеличивает время компиляции двумя способами:

1. Объем кода, который они добавляют в каждую единицу компиляции (файл .cpp), которая включает их, легко во много раз больше, чем сами файлы cpp. Чтобы представить это в перспективе, catch2.hpp составляет 18000 строк, тогда как большинство людей (даже IDE) начинают бороться с редактированием файлов размером более 1000-10000 строк.
2. Количество файлов, которые необходимо перекомпилировать при редактировании заголовка, не входит в истинный набор файлов, которые от него зависят.

Да, есть смягчения, такие как предварительное объявление, который ощутил недостатки или сутенер идиома, которое является абстракцией с ненулевой стоимостью. Несмотря на то, что C++ безграничен в том, что вы можете делать, вашим коллегам будет интересно, что вы курили, если вы слишком далеко отойдете от того, как это должно быть.

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

Чтобы просто ответить на этот вопрос, C++ - гораздо более сложный язык, чем другие языки, доступные на рынке. У него есть устаревшая модель включения, которая анализирует код несколько раз, а его шаблонные библиотеки не оптимизированы для скорости компиляции.

Грамматика и ADL

Давайте посмотрим на грамматическую сложность C++ на очень простом примере:

x*y;

Хотя вы, вероятно, скажете, что приведенное выше выражение является выражением с умножением, это не обязательно так в C++. Если x является типом, тогда оператор фактически является объявлением указателя. Это означает, что грамматика C++ контекстно-зависима.

Вот еще один пример:

foo<x> a;

Опять же, вы можете подумать, что это объявление переменной «a» типа foo, но это также можно интерпретировать как:

(foo < x) > a;

что сделало бы это выражением сравнения.

В C++ есть функция под названием Argument Dependent Lookup (ADL). ADL устанавливает правила, которые определяют, как компилятор ищет имя. Рассмотрим следующий пример:

namespace A{
  struct Aa{}; 
  void foo(Aa arg);
}
namespace B{
  struct Bb{};
  void foo(A::Aa arg, Bb arg2);
}
namespace C{ 
  struct Cc{}; 
  void foo(A::Aa arg, B::Bb arg2, C::Cc arg3);
}

foo(A::Aa{}, B::Bb{}, C::Cc{});

Правила ADL гласят, что мы будем искать имя «foo», учитывая все аргументы вызова функции. В этом случае все функции с именем «foo» будут рассматриваться для разрешения перегрузки. Этот процесс может занять время, особенно если имеется много перегрузок функций. В контексте шаблонов правила ADL становятся еще более сложными.

#включают

Эта команда может существенно повлиять на время компиляции. В зависимости от типа файла, который вы включаете, препроцессор может скопировать только пару строк кода или тысячи.

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

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

Функция модулей обеспечивает решение этой проблемы на уровне языка. Он доступен начиная с версии C++ 20.

Шаблоны

Скорость компиляции шаблонов непростая. Каждая единица перевода, которая использует шаблоны, должна быть включена, и определения этих шаблонов должны быть доступны. Некоторые экземпляры шаблонов превращаются в экземпляры других шаблонов. В некоторых крайних случаях создание экземпляра шаблона может потреблять много ресурсов. Библиотека, использующая шаблоны и не предназначенная для скорости компиляции, может вызвать проблемы, как вы можете видеть при сравнении библиотек метапрограммирования, представленных по этой ссылке: http://metaben.ch/. Их различия в скорости компиляции значительны.

Если вы хотите понять, почему одни библиотеки метапрограммирования лучше подходят для компиляции, чем другие, посмотрите это видео о Правиле Хиля.

Заключение

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

P.S - Я работаю в Incredibuild, компании по ускорению разработки программного обеспечения, специализирующейся на ускорении компиляции C++, добро пожаловать в попробуй бесплатно.