LINUX.ORG.RU

Кто может объяснить, почему webkit-gtk так долго компилируется?

 , , , ,


0

1

Это для меня не новость, я уже лет 5 в курсе этого факта, всегда страдал, но сейчас решил спросить: какого, черт возьми, дьявола, ребята?

Браузерный движок? Ладно, но в комплекте фирефокса тоже браузерный движок + сам браузер, но какова разница:

firefox-48:

merge time: 32 minutes and 20 seconds.
webkit-gtk-2.12.3
merge time: 1 hour, 35 minutes and 14 seconds

чего он так долго козла рожает?


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

anonymous ()
Ответ на: комментарий от anonymous

У тя слишком долго жирнолис компилируется чё-то.

так это в рабочее время, я параллельно в хроме тусовался, торренты кочал и музыку лосслесс слушал, а вот в случае с вебкит-гтк, то процессорное время было отдано полностью на сборку пакета.

slon ()

шаблоны... те кто все еще юзают 32 бита зачастую и собрать-то не могут - тупо адрессного пространства не хватает

anonymous ()

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

ananas ★★★★★ ()
Ответ на: комментарий от anonymous

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

slon ()
Ответ на: комментарий от slon

Я, собственно, об полторачасовой компиляции чтобы просто посмотреть приложение.

l4gfcm ()
Ответ на: комментарий от l4gfcm

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

slon ()
Ответ на: комментарий от annulen

тогда нет, вот сейчас поставил, реально быстрее будет компилироваться?

slon ()

В основном от навороченности компилятора зависит (версия, предпринимаемые оптимизации, выделенная память под компиляцию, механизмы кэширования файлов с диска). И ещё программы на C++ очень долго компилируются (по сравнению с программами на C, Java, например). Почему? Шаблоны должны быть раскрыты компилятором в многокилометровые простыни, установлены многочисленные статические связи между объектами кода - это давняя ошибка модуляризации C/C++, так они от этого и не отошли. Например, в отличие от Borland Pascal и Sun Java, где модульность стоит на первом месте и не нужно всю программу представлять одной большой «простынёй» в памяти и ходить по ней, строя результирующий бинарный код, модули компилируются отдельно, линковка осуществляется между готовыми бинарными объектами из ранее скомпилированных модулей — .TPU/.BPU, .class, соответственно. В Java линковка кода из модулей осуществляется в рантайме по понятным причинам, в C/C++ для статической линковки придумали .OBJ, .o, для динамики — .DLL, .so, но всё равно и этого недостаточно — компилятору необходимо знать о коде программы на C/C++ ВСЁ, чтобы построить правильный бинарник, и программа могла правильно работать. Из-за этого и ТОРМОЗААА.

iZEN ★★★★★ ()

FreeBSD 11.0-PRERELEASE компилируется 4 часа 30 минут на AMD Phenom II X4 810 и 12 ГБ ОЗУ. И это ещё только самое необходимое из системы — всё лишнее на десктопе поотключал в src.conf, убрал опции отладки. Примерно 3 часа компилируется один только LLVM/Clang 3.8.0 из состава системы - больше всего напрягает. (Накой чёрт его в состав системы включили? Использовали бы бутстрап из соответствующего порта.)

iZEN ★★★★★ ()
Ответ на: комментарий от f1u77y

Твой файловый менеджер может показать рекурсивно все картинки из директории, в которой содержатся еще другие директории с картинками?

slon ()

merge time: 1 hour, 35 minutes and 14 seconds

нашёл, о чём жаловаться

я порты собирал, так у меня там аж три штуки вебкитов, то вебкит, то вебкитгтк, то ещё что-нибудь. суммарно пять суток компилировались

buratino ★★★★★ ()
Ответ на: комментарий от ananas

кроме этого огнелис при сборке ccache использует

Как это включить? Недавно делал bisect, так после каждого шага почти всё заново пересобиралось из-за unified sources. Меняется один файлик, а пересобирается вся связка.

Раньше был ключ, но он сейчас не работает.

i-rinat ★★★★★ ()
Ответ на: комментарий от f1u77y

как называется файловый менеджер?

там ведь можно не иконками, а тхумбнейлами, например 256х256 и такого типа, да?

slon ()

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

anonymous ()
Ответ на: комментарий от i-rinat

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

ananas ★★★★★ ()
Ответ на: комментарий от ananas

У меня ccache установлен и постоянно включен.

С исходниками Firefox проблема в другом. Они уже давно не собирают файлы по отдельности. Вместо этого несколько cpp файлов склеиваются в один — создаются файлы типа Unified_cpp_widget0.cpp, в который includ'ятся исходники. Компилируются уже эти Unified_*. При сборке с нуля такая склейка полезна, но при bisect'ах это сплошное мучение. Меняются несколько файлов, и все задетые Unified_* компилируются заново. Почти все шаги bisect'а, кроме последних двух-трёх, это сборка всего Firefox заново.

У них есть какой-то режим, где объектники скачиваются из их артифактория, но я хочу быть уверенным, что сборка была моей версией компилятора, что бы не разгребать шальные баги от каких-то несоответствий.

i-rinat ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.