Открыт исходный код компилятора C++ Zapcc

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

Алсо, ты считаешь отсутствие прироста скорости в случае модификации pch.h в сравнении полная пересборка <-> частичная?

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

Если частичная, то обновление либ происходит не так часто. А от какого-нибудь boost filesystem может зависеть пол проекта без всяких pch.

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

Это такие копейки, что даже говорить смешно.

Копейка рубль бережёт.

Такое. Можно кинуть в tmpfs и проверить, но мне лень, а ты скорее всего прав. // на самом деле оно и так в ram будет всю сборку сидеть, скорее всего, тому шо линукс

Общая идея ясна как свет

Увы, я не царь.

Не боги горшки обжигают.

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

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

zapcc нужен, чтобы не проводить их инстанциацию каждый раз повторно. И, несмотря на то, что он ускоряет и холодную сборку (избегая повторной инстанциации одних и тех же шаблонов разными файлами), основной его ценностью мне видится ускорение типового цикла «поправил файл-посмотрел что получилось», за скорость которого так любят скриптовые языки типа питона. C++ традиционно проигрывал в этом из-за того, что пересборка даже одного файла могла занимать от двух-трех до десятка секунд, тогда как в скриптовых языках результат можно было лицезреть практически мгновенно.

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

Никакие другие решения такого раньше не позволяли. PCH не инстанциируют шаблоны, ccache - и вовсе просто выдает ранее собранный файл из кэша, если входные данные идентичны. SSD, RAM-диски - всё это мимо кассы. Тормозит просто инстанциация, а она для каждого файла производится в памяти, одним процессором и в один поток. Единственное, что можно было делать раньше - это использовать extern template (ускоряло раза в два за счет того, что не генерировало код, но начальная часть инстанциации всё равно проводилась, и всё это вовлекало ненужную писанину), и покупать самый быстрый процессор на рынке. Так что выход zapcc - это важное событие для тех, кто пишет на C++. Для тех, кто просто собирает код, это событие гораздо меньшего масштаба, конечно - полную сборку всегда можно ускорить, увеличив её параллельность. Однако для одного собираемого файла это не работает, и тут zapcc и интересен.

По сведениями агентства ОБС, последнее время упоротые линуксоиды плюсами отнюдь не брезгуют.

Вот так сюрприз сейчас. Но надолго ли...

А вот и интересная заметка в README.md:

### When was the source last merged with LLVM trunk?

This open-source release was last merged with LLVM r307021 on 2017-07-03.

Т.е. всё, уже как год код более не обновляли (около 28000 коммитов).

А повторная пересборка - всего лишь 0.3 секунды.

Интересно, реально ли теперь покопаться в фаерфоксе с помощью этого zapcc. Перелинкует ли он за несколько секунд...