История изменений
Исправление quiet_readonly, (текущая версия) :
А есть предпосылки к заметному ускорению? Как-то на reddit-е были сообщения о том, что народ пробовал использовать VC++ с поддержкой модулей на более-менее реальных кодовых базах и особого выигрыша не было.
Огромное ускорение будет в IDE, объясню почему.
В компиляторах C++ есть 6 стадий: три относятся к фронтенду (препроцессинг и лексический анализ, парсинг в AST, проход AST для проверки семантики), три относятся к бекенду (обход AST для генерации IR - промежуточного кода, оптимизация IR, трансляция IR в машинный код вместе с распределением регистров и специфичными оптимизациями).
Тормозят две стадии: парсинг AST и оптимизация IR.
- оптимизация тормозит потому что в каждом файле получается много инструкций IR после обработки include, и после обработки модулей из C++2x так же много IR, то есть ничего не меняется
- а вот парсинг AST тормозит, потому что инстанцирование всех конкретных специализаций всех шаблонов происходит заново для каждого файла в ходе повторного разбора заголовков, по сути это задача сложности O(N*H), где N - число файлов в проекте, H - число заголовков, используемых проектом. Модули эту сложность снижают до O(N+H)
Поскольку в компиляторе есть фронтенд и бекенд, ускорение фронтенда погоды не сделает (ну в лучшем случае 50% или немного выше выигрыш будет).
А вот в IDE при обработке кода для автодополнения, подсветки и т.п. используется только фронтенд компилятора без бекенда, и ускорение будет колоссальным с учётом того что IDE видит, что изменился только один файл и используемые им модули обновлять не надо. Сейчас libclang один C++ файл среднего проект на моей машине парсит в среднем за 1 секунду, в худших случаях за 3-5 секунд. С модулями будет парсить так же быстро, как модуль go/ast языка golang: за милисекунды.
Исходная версия quiet_readonly, :
А есть предпосылки к заметному ускорению? Как-то на reddit-е были сообщения о том, что народ пробовал использовать VC++ с поддержкой модулей на более-менее реальных кодовых базах и особого выигрыша не было.
Огромное ускорение будет в IDE, объясню почему.
В компиляторах C++ есть 6 стадий: три относятся к фронтенду (препроцессинг и лексический анализ, парсинг в AST, проход AST для проверки семантики), три относятся к бекенду (обход AST для генерации IR - промежуточного кода, оптимизация IR, трансляция IR в машинный код вместе с распределением регистров и специфичными оптимизациями).
Тормозят две стадии: парсинг AST и оптимизация IR.
- оптимизация тормозит потому что в каждом файле получается много инструкций IR после обработки include, и после обработки модулей из C++2x так же много IR, то есть ничего не меняется
- а вот парсинг AST тормозит, потому что инстанцирование всех конкретных специализаций всех шаблонов происходит заново для каждого файла в ходе повторного разбора заголовков, по сути это задача сложности O(N*H), где N - число файлов в проекте, H - число заголовков, используемых проектом. Модули эту сложность снижают до O(N+H)
Поскольку в компиляторе есть фронтенд и бекенд, ускорение фронтенда погоды не сделает (ну в лучшем случае 50% или немного выше выигрыш будет).
А вот в IDE при обработке кода для автодополнения, подсветки и т.п. используется только фронтенд компилятора без бекенда, и ускорение будет колоссальным с учётом того что IDE видит, что изменился только один файл и используемые им модули обновлять не надо. Сейчас libclang файл проектов на моей машине парсит в среднем за 1 секунду, в худших случаях за 3-5 секунд. С модулями будет парсить так же быстро, как модуль go/ast языка golang: за милисекунды.