The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск сборочного инструментария Qbs 2.0, opennews (?), 25-Апр-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


14. "Выпуск сборочного инструментария Qbs 2.0"  +1 +/
Сообщение от Аноним (14), 26-Апр-23, 00:20 
"В сотни раз" -- сильное преувеличение. https://hamelot.io/programming/make-vs-ninja-performance-com.../ И скорость сборки зависит не от инструментария автоматизации сборки, а от компилятора -- он требует больше всего ресурсов (любых, не важно, ЦП, памяти или I/O), поэтому производительность упирается именно в него.
Ответить | Правка | Наверх | Cообщить модератору

33. "Выпуск сборочного инструментария Qbs 2.0"  +/
Сообщение от Ванёк (?), 26-Апр-23, 10:55 
Да, именно так, всё упирается в компилятор, а не в make или что-то ещё.
Ответить | Правка | Наверх | Cообщить модератору

36. "Выпуск сборочного инструментария Qbs 2.0"  +4 +/
Сообщение от Аноним (36), 26-Апр-23, 15:16 
Для полной пересборки да, все упирается в производительность компилятора.

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

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

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

53. "Выпуск сборочного инструментария Qbs 2.0"  +/
Сообщение от InuYasha (??), 27-Апр-23, 12:01 
По-моему, сравнивать даты изменения *.c и *.obj умел ещё make - разве нет?
Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск сборочного инструментария Qbs 2.0"  +/
Сообщение от InuYasha (??), 27-Апр-23, 12:03 
Почитал остальной ваш тред - можете не отвечать :D
Ответить | Правка | Наверх | Cообщить модератору

38. "Выпуск сборочного инструментария Qbs 2.0"  +/
Сообщение от Аноним (38), 26-Апр-23, 15:50 
>> Время пересборки (incremental build)
> скорость сборки зависит не от инструментария автоматизации сборки, а от компилятора

По вашей ссылке речь идёт о чистой сборке, а начальное сообщение — про инкрементальную сборку, которая нужна разработчикам десятки и сотни раз в день.

Для make совершенно типично долго обходить все каталоги, чтобы через 10+ секунд скомпилировать и перелинковать один файл. Для больших проектов это просто ад.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

43. "Выпуск сборочного инструментария Qbs 2.0"  +/
Сообщение от Ванёк (?), 26-Апр-23, 17:19 
Пересборку make делает очень быстро. У меня каждый раз делается замер общего времени компиляции/сборки, времени компиляции каждого модуля, времени линковки и прочего. Причём сценарии сборки make довольно большие (более 1500 строк чистого кода - это уже после вычета комментариев и пустых строк) и используется Perl для вспомогательных целей. Вывод следующий: как для полной сборки проекта, так и для частичной пересборки, ситуация примерно одна и та же, а именно: практически всё время затрачивается на работу компилятора gcc/clang, а всё остальное (make, линковщик...) занимает очень незначительное время, уменьшение которого на общее время как-то существенно повлиять не может.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру