Comments 29
Мы сократили время компиляции с ~319 мс до ~69 мс
почему то приходят на ум кроты из старого мультфильма про Дюймовочку:
Ну, справедливости ради, это очень хорошее сокращение.
Я вот как-то комп себе девелоперский обновил, на 90% из-за того что на старом, один long term проект полностью компилился полторы-две минуты. Задолбался я каждые 10-15 минут ждать по минуте. Для разработки хватало, а время компиляции раздражало жутко. Так что ускорение компиляции примерно в пять раз - вполне себе достойная цель.
На старой машинке - одиннадцать часов. На новой - три.
Я что-то припоминаю у меня ядро какого-то Линукса компилировалось кроскомпиляцией в 2006 году, ну примерно может минут десять-полчаса, в общем кажется не больше часа.
Что ж вы за зверей разводите? Они на библиотеки ни как не делятся? Может построили не правильно?
Я думаю при таких масштабах как у вас вам никакие локальные советы-улучшения, как в этой статье, все равно не помогут.
Я про компиляцию хрома. :)
Ему числомолотилка особо мощная не нужна. Ему потоков побольше. На четырех ядрах (i5) ~ 10-11 часов. На 16 (i7 средний) ~ 3 часа, но еще от опций зависит, конечно.
Ловите гентушника!
А что сразу гентушник! Привыкли чуть что, гентууууушник... :)
Виндузятник на 80%. Просто специфические вещи приходится делать. Например, по дефолту, хромиум компилится без поддержки проприетарных кодеков. А мне надо! Или биндинги наружу выставить специфические. Начинал как все, с CefSharp. Ну а потом покатился по наклонной. И вот меня уже застают за компиляцией хрома. Первые разы было стыдно. Позорище. Горе в семье.
Потом родные привыкли, только шушукаются за спиной. И ребенка больше не спрашивают в школе, чем папа занимается.
А я поддержу гентушника). Разработчики Хрома постоянно какую-то фигню делают - прячут http\https из адреса, увеличивают размеры UI контролов, или впихивают ненужные мне элементы. Вот и приходится исправлять и пересобирать.
Но у меня как-то шустрее собирается: На i5-12600 (macos) — 2,5 часа, на i7-13700 (win11) — чуть больше часа. Оба на SSD.
Сборка Хрома тот ещё квест.
Целый блог ведётся про постоянные проблемы при сборке
https://randomascii.wordpress.com/2023/03/08/when-debug-symbols-get-large/
В C++ это надо умножать на количество юнитов компиляции где этот заголовок используется. Большие проекты состоят из десятков тысяч юнитов, а учитывая что fmt используется в основном в связке с логированием то достаточно большая часть будет его инклюдить.
в С++20 уже можно использовать import std которое должно эти проблемы решить
Модули не помогут в случае использования шаблонов (они также создаются на месте использования отдельно для каждого юнита компиляции), а именно от них происходит большая часть замедления времени компиляции. Хотя возможно не в этот конкретном случае, хз.
(и import std это C++23 кстати)
В этом случае нет, шаблоны нужно будет создавать в любом случае и это уже оптимизировано (не знаю насколько хорошо)
(и import std это C++23 кстати)
все реализации сделали это расширением в С++20
Както замерял время компиляции в своих проектах. И оно большое не из-за шаблонов. Скорее всего, оно большое просто из-за количества кода в хидерах - их ведь надо загрузить, подставить, раскрыть макросы, спарсить...
Очень интересно все это выглядит. Я когда пришел на проект занялся как раз оптимизацией времени сборки и расхода ресурсов: за 4 месяца работы удалось снизить время сборки с 11 до 8 минут, расход рам с 211 до 170 и по процу почти 15% (сугубо по стресс тесту - сервер мморпг )
спасибо за статью
У меня маленькие любительские проектики, "stdio.h" хватает за глаза, но иногда не уследишь за форматированием. Существуют ли какие-то утилиты, которые можно натравливать на исходники в Pre-Build Event ? Этакий статистический анализатор, заточенный на (v)printf и scanf ?
<spoiler title="Осторожно, боль ))">
Мой первый справочник по С, табличка строки форматирования... Сколько было радости (после Фортрана) от этой тоненькой книжки, 96 страниц чуть шире формата A6. Когда в начале 90-х в руки попал толстый кирпич Страутсрупа с вырвиглазными << и >> я понял, что не смогу привыкнуть к потоковуму вводу-выводу. Один << endl вместо "\n" чего стоит.</spoiler>
>> Этакий статистический анализатор
Извиняюсь, речь конечно же про статический анализатор. И ещё непонятно почему у меня не спрятался спойлер.
Существуют ли какие-то утилиты, которые можно натравливать на исходники в Pre-Build Event?
В компиляторе gcc есть атрибут `format`, с помощью которого можно заставить компилятор проверять аргументы функции:
int Printf (const char *format, ...)
__attribute__ ((format (printf, 1, 2)));См. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
Для MSVS есть `_Printf_format_string_`, см. https://stackoverflow.com/a/6849629/12479250
Для clang наверняка тоже можно найти нечто подобное.
Экономия по факту бессмысленная. В подавляющем большинстве пользовательских программ наверняка уже <string> включается почти уж везде, а уж тем более, где нужна эта библиотека fmt.
Спасибо за интересную статью!
Простите за оффтоп, но есть небольшой вопрос. Библиотека {fmt}, про которую идет речь, пример классной полезной библиотеки. Однако я, как программист С++ с 10+летним опытом, про нее ничего не знал до этой статьи. В моем случае это объяснятся двумя факторами: а) я пишу на Qt, в котором есть почти все, что можно захотеть, б) задачи, которые я решаю, специфичные, нешаблонные, неповторяемые по большей части. Так вот вопрос такой:
Есть ли какие-то более-менее централизованные базы/опиcания/списки/дайджесты библиотек на С++? В мире python, как кажется со стороны, в этом плане все неплохо.
Если более конкретно, то прямо сейчас меня интересуют:
1) библиотеки для создания видео (здесь Qt подкачал, к сожалению) - порождение кадров и склейка их со сжатием и наложением звука. Пока знаю только про ffmeg.
2) неcтандартные виджеты на Qt. Изредка обращаюсь на эту тему к github`у, но никогда оттуда ничего интересного на эту тему не видел. Под нестандартными имею в виду что-то типа такого.
Заранее спасибо.
Есть ли какие-то более-менее централизованные базы/опиcания/списки/дайджесты библиотек на С++?
1) библиотеки для создания видео (здесь Qt подкачал, к сожалению) - порождение кадров и склейка их со сжатием и наложением звука. Пока знаю только про ffmeg.
вот здесь:
https://habr.com/ru/articles/738350/
я попытался сформулировать что-то о том как выглядит работа с видео изнутри, но вы, как мне кажется, ищите с точки зрения того как это выглядит снаружи. Если найдете что то полезное, мне будет приятно. Под Линукс была аналогичная технология GStreamer называлась, не знаю что от нее осталось.
централизованные базы/опиcания/списки/дайджесты библиотек на С++
Важная вещь, спасибо автору оригинала и за перевод.
Одно время тоже решал проблему скорости компиляции fmt, но не слишком долго и упорно. У меня была какая-то идея (помню смутно) что в отладочной версии использовать форматирование типа printf() которое не проверяет типо-безопасность но ускоряет компиляцию пока работаешь. Когда собираешь релиз (или на CI) - уже можно выполнить полную проверку, когда на этапе компиляции детектируются проблемы с несоответствием фактических типов указанным в строке форматирования.
а почему бы не добавить fmt и string в precompiled headers?
Оптимизируя неоптимизируемое: ускорение компиляции C++