Я слышал от кого-то, что большие проекты с большим количеством предупреждений в коде строятся значительно медленнее, чем с небольшим количеством предупреждений (конечно, предполагается, что компилятор настроен на чувствительность высокого уровня).
Есть ли разумное объяснение, или, может быть, кто-то может поделиться своим опытом по этой теме?
В GCC компилятор (например, gcc для C или g++ для С++) предупреждения требуют небольшого количества CPU время. Использовать, например. gcc -ftime-report, если вы хотите получить подробный отчет о времени компилятора. Диагностика предупреждений зависит от уровня оптимизации.
Но оптимизация (особенно на высоком уровне, например -O2 или более) занимает гораздо больше времени, чем предупреждения. Эмпирически оптимизированное время компиляции пропорционально размеру блока компиляции и квадрату размера (например, в количестве Gimple инструкций или в строках кода C) самой большой функции. Поэтому, если у вас есть огромные функции (например, некоторые функции из десяти тысяч строк в некотором сгенерированном C-коде), вы можете разделить их на более мелкие части.
В первые дни MELT (плагин GCC и экспериментальная ветвь GCC -GPLv3 + лицензированы - реализация DSL для GCC, который я разработал и до сих пор работаю), он генерировал огромные функции инициализации в C (сегодня это меньше, чем случай, инициализация разделяется на многие функции С++, например, gcc/melt/generated/warmelt-base.cc из ветки MELT GCC в качестве примера). В это время я построил компиляцию -O2 по сравнению с длиной этой функции инициализации и измерил время компиляции по своей длине. Вы также можете поэкспериментировать с manydl.c. Опять же, квадрат наибольшей длины функции является экспериментальной мерой, но может быть объяснено проблемами распределения регистров. Кроме того, J.Pitrat также заметил, что огромные генерируемые функции C - благодаря его интересному CAIA система исчерпала компилятор.
Кроме того, выводятся предупреждения, а иногда IDE или терминал, считывающий вывод компилятора, могут замедляться, если у вас много предупреждений.
Конечно, поскольку несколько раз комментировали, предупреждения компилятора - ваши друзья (поэтому всегда компилируйте, например, gcc -Wall). Поэтому, пожалуйста, улучшите свой код, чтобы вообще не получать предупреждения. (В частности, инициализируйте большинство ваших локальных переменных - я обычно инициализирую их все, поскольку компилятор может оптимизировать, удалив некоторые инициализации, если можно доказать, что они бесполезны).
Кстати, вы можете настроить GCC с помощью, например, MELT, чтобы добавить свои собственные настраиваемые предупреждения (например, чтобы проверить соответствие правил кодирования).
Кроме того, в С++ со странными шаблонами вы можете написать несколько десятков строк, которые требуют много времени для компиляции (или даже сбой компилятора из-за нехватки памяти, см. this вопрос).
Это зависит от того, что на самом деле представляют предупреждения.
В качестве примера, если есть много предупреждений "переменная не используется" и предупреждения "condition in" if "always true/false", это может означать, что существует много ненужного кода, который компилятор должен проанализировать и затем удалите во время оптимизации.
Для других предупреждений могут быть другие последствия. Например, рассмотрите предупреждение "переменная - само инициализация", вызванное чем-то вроде int i = i;. Я бы предположил, что это может добавить целую кучу осложнений/накладных расходов (где компилятор пытается определить, является ли переменная "живой" или может быть оптимизирована).
Это, вероятно, будет сильно зависеть от компилятора и того, как оно реализовано.
При этом есть два надежных источника замедления:
Печать самих предупреждений является нетривиальной задачей, она требует обширного форматирования, потенциального доступа к файлу и всех этих заметок (макрообмена, создание экземпляра шаблона) и, наконец, нажатия на устройство ввода/вывода.
Испускание указанных предупреждений со всеми этими макрообменами и данными о создании шаблона может быть и нетривиальным. Кроме того, если они собраны в первую очередь и будут выпущены только в конце процесса компиляции (вместо того, чтобы транслироваться по мере их создания), то растущее потребление памяти также замедлит вас (требуя большего количества страниц, предоставляемых ОС,... )
В целом, с точки зрения инженерии, я не ожидаю, что авторы компиляторов будут очень беспокоиться о стоимости испускания диагностики; пока это разумная стоимость, кажется, мало стимулов для оптимизации пары миллисекунд, когда человеческое вмешательство будет необходимо в любом случае.
Кого волнует, если ваша сборка займет 10% дольше из-за того, что компилятор печатает массу предупреждений? Проблема - это код, о котором вы предупреждаете, а не дополнительное время. Кроме того, 10%, вероятно, сильно завышены для накладных расходов при печати даже очень большого количества предупреждений.