Libxml2 - набор гигантских файлов.

http://svn.gnome.org/viewvc/libxml2/trunk/testapi.c?view=log
Больше мегабайта :(

1423882 byte(s)

Ну и ладн, надеюсь подобные файлики всё же редкость. Хотя если нечто подобное живёт например в Qt4 ... ТО я пожалуй поостерегусь выставлять такие же параметры для g++ (как изначально хотел)

А прикинь как ты будешь компилить код на С++ с кучей шаблонов

testapi.c: Automatically generated by gentest.py from libxml2-api.xml

А вот xmlschemas.c - да, ручная работа.

Собирать Gentoo на mips r5k, 180 Mhz - это сильно. Ну а за мегабайтные исходники казнить сразу.

Оно до сих пор ... компилится. Virt/res было до 40/38 Мb, сейчас меньше (37/31).

Под впечатлением 800 минутной компиляции наваял строчку, после пяти минут чтения манов:


find путь -name \*.c* -print | xargs /usr/bin/du -h | sort -h | less

В принципе и в ядре, и в mesa/xserver и в cairo есть уже файлики под 600 Кб.

В «лёгком» КДЕ3 есть и под 4 Мб
3,9M /mnt/hdd1/src/kdepim-3.5.10/kresources/groupwise/soap/soapC.cpp


Так что флаги были срочно поменяны на --param ggc-min-expand=30 --param ggc-min-heapsize=16384

Но ушедшему поезду (запущенному компилятору) это уже не поможет ....

> Да, компилится оно на mips r5k, 180 Mhz.

а distcc заюзать не? или так кайфа мало? :)

Ура, оно закомпилировалось (этот громадный автосгенерированный файл). Надо будет на более быстром десктопе тщательнее проверить эффект этих флагов, пока, если не считать gcc testsuit громадных С файлов нашлось (больше 1 мб) не так уж много, по крайней мере в NetBSD (давным-давно кстать дерево не обновлял ...)

Места мало, на десктопе.

Максимум 1 Гб, да и тот на разделе куда и так NFS сервер смотрит ....

Хотя конечно пора. Правда, сейчас десктоп занят починкой КДЕ, компиляцией его тобиш, благо предыдущую я убил неосторожным rm (libxcb-xlib.so.0 до какого-то момента присутствовал в моей Слакваре, потом я его после ручного апгрейда Хов прибил - вот и повод для некоторой перекомпиляции появился... так что прямо сейчас лишняя нагрузка в виде кросс-компилера не нужна.)

Хотя если прибить тут Х сервер, с Мозиллой и композитингом - сразу станет процентов на 40 побыстрее. Но постить с lynx я пока не привых.

>--param ggc-min-expand=0 --param ggc-min-heapsize=8192

у вас 32 Мб на VPS ? увеличьте значение, пока RSS не будет около 70-80% доступной для VPS памяти, иначе собирать будет очень долго, и уж тем более если файлы с исходниками большие.
А еще луше собрать то что собираете используя distcc , на другой машине, где нормальный обьем памяти

/// прочитала про mips, поставьте ggc-min-heapsize=16384 или можно даже чуть больше

и наверное стоит подумать о кросс-комиляции....

PS: у GCC есть эвристика по определению параметров ggc, если машина не VPS и вся память и свап реальны, лучше вообще этот параметр не задавать, просто на OpenVZ/Virtuozzo рапортуется больше памяти, чем на самом деле будет доступно, вот GCC и вылетает, если ему не ограничивать, если вся память реальна - пусть компилит с автоопределением.

Своп по сети я не осилил, своп на винт не хочу (Irix установленный запороть могу - а он мне ещё пригодится, может быть).

На 256 Мб перекомпиляция самого гцц по самому-самому краю ходит, видимо из-за постоянной подкачки страниц через NFS трафик между машинами был 5 Мб/с в течение часов, хотя как ни удивительно - сетевухи выдержали.