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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2) Тот факт, что инструментальная цепочка часто разделяется на несколько двоичных файлов (make, preprocessor, compiler, ассемблер, архиватор, 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 также вызывает некоторые программы только для получения информации.

Building C/С++: что действительно происходит и почему так долго

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

• Конфигурация
• Сборка встроенного инструмента
• Проверка зависимостей
• Подборка
• Связь

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

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

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

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

Сборка встроенного инструмента

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

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

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

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

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

Компиляция

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

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

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

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

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

#include "BigClass.h"

class SmallClass
{
   BigClass m_bigClass;
}

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

class BigClass;

class SmallClass
{
   BigClass* m_bigClass;
}

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

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

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

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

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

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

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

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

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

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

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

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

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

Как уже отмечалось, компилятор тратит много времени на создание экземпляра и снова создает шаблоны. До такой степени, что есть проекты, которые сосредоточены на этом конкретном предмете, и требуют наблюдаемого 30-кратного ускорения в некоторых действительно благоприятных случаях. См. http://www.zapcc.com.