Я подозреваю, что препроцессор gcc работает неправильно, потому что существует необъяснимая корреляция времени компиляции с комментариями или без них и с оптимизацией или без нее.
У меня есть огромный сгенерированный Matlab c-файл (около 70 000 строк).
Я заметил, что когда я компилирую его с уровнем оптимизации -O3, компиляция занимает> 30 минут. При отключении оптимизации (-O0) это занимает всего 4 минуты. Это было именно то, что я ожидал, потому что оптимизация может быть сложной для больших файлов.
Но если я сгенерирую тот же файл в Matlab без комментариев (или удалю их с помощью редактора), он скомпилируется за 16 минут с оптимизацией и за 2 минуты без оптимизации.
Откуда берется фактор 2? Я ожидаю, что оптимизация будет выполнена после предварительной обработки, а предварительная обработка должна удалить любые комментарии. Это привело бы к фиксированной разнице во времени, независимой от уровня o. Я запутался.
Я попытался отобразить предварительно обработанный вывод (с параметром gcc -E), но комментариев нет. Если я дополнительно использую опцию -C, есть комментарии.
Если я удаляю пустые строки и последовательные пробелы, это также влияет на время компиляции. Время компиляции кажется линейным размером файла в зависимости…
Вы предполагаете, что компилятор реализует каждую фазу независимо. — person toto-w schedule 14.08.2019
Основные вопросы по бенчмаркингу. Вы запускали оба несколько раз? Возможно, вы просто тестируете кэширование диска. Вы полностью очищали исходное дерево между запусками? Не make clean, который не всегда получает все, начните со свежего исходного дерева. Возможно, у вас все еще есть кешированные единицы компиляции. Вы используете что-то вроде ccache? — person toto-w schedule 14.08.2019
И убедитесь, что ваша машина не делает ничего другого во время компиляции, особенно что-то интенсивное на диске. — person toto-w schedule 14.08.2019
Можете ли вы загрузить свой источник куда-нибудь для независимой проверки? — person toto-w schedule 14.08.2019
Современные компиляторы C не реализуют предварительную обработку так отдельно, как раньше, но вы правы в том, что комментарии удаляются очень рано в общем процессе (фаза перевода 3, на стандартном языке C) и что их присутствие или отсутствие во входных данных < i>не должно вызывать двухкратную разницу во времени компиляции. — person toto-w schedule 14.08.2019
В дополнение к комментарию базовый бенчмаркинг может быть полезно также выполнить сборку с помощью clang или другой версии gcc. Всегда хорошо иметь несколько точек сравнения для неожиданного поведения. — person toto-w schedule 14.08.2019
Спасибо за ваши предложения. Я использую Windows 10 с eclipse и форком GCC версии 4.8.5. — person toto-w schedule 15.08.2019
Я использую Windows 10 с eclipse и форком GCC версии 4.8.5. @Schwern: Время компиляции воспроизводимо и не зависит от других действий (поскольку этим занято только одно ядро). Перед каждым запуском я меняю char в большом исходнике, нажимаю сохранить и потом строить. Обращаю внимание, что компилируется только этот один файл. Извиняюсь! Мне не разрешено делиться этим кодом. Коллега скомпилировал файл на компьютере с Linux (аналогичное оборудование) менее чем за 5 минут. Я предполагаю, что это как-то связано с дрянным управлением памятью Windows — person toto-w schedule 15.08.2019
Я нашел причину:
Кто-то (на ранней стадии проекта) включил опцию «-Wa,-amhls», которая заставляет ассемблер генерировать комбинированный файл .lst длиной > 500 000 строк из входных файлов .S и .C.
Создание этого файла на компьютере с Windows занимает более 30 минут. (Линукс намного быстрее!)
Также по этой причине время сборки зависит от оптимизации и включения/отключения комментариев. И то, и другое влияет на длину этого файла .lst.
Если эта опция отключена, мой проект собирается менее чем за 3 минуты.