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

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

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

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

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

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

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

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

См. также: C++ Часто Подвергаемые сомнению Ответы

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

#include "BigClass.h"

class SmallClass
{
   BigClass m_bigClass;
}

Компиляции намного медленнее, чем:

class BigClass;

class SmallClass
{
   BigClass* m_bigClass;
}

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

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

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

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

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

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

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

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

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

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

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