Как gnu Make се справя със зависимостите?

в момента генерираме файл на зависимост за всеки .o. Но когато правите инкрементално изграждане, Make чете от файла на зависимостите за зависимости за всеки .o. Make проверява ли времевия печат на тези зависими файлове и го сравнява с .o? Ако е така, възможно ли е да се кешира състоянието на зависимостите, за да се избегнат твърде много I/O удари поради дублирани проверки на състоянието за всеки обектен файл?

for example, 
a.o: h1.h h2.h
    gcc...
b.o: h1.h h2.h
    gcc...

Ако кешираме състоянието на h1.h и h2.h, когато изгражда a.o, запазваме ли две проверки, когато изграждаме b.o?

Не съм запознат със системата make, но в момента търся начини да подобря нейната производителност на голям наследен C проект.


person wei    schedule 09.08.2012    source източник
comment
това наистина ли е проблем? Колко зависимости проследявате? Колко време отнема изграждането сега?   -  person n8wrl    schedule 10.08.2012
comment
да, файлов I/O е проблем, бавен е. Нашият изходен код достигна размер от 2,5G и за типичен C файл имаме около 800 зависимости. Изграждането обикновено отнема 3-4 часа. Но разбира се, това не е единственият проблем, който имаме, и със сигурност не е най-големият, просто искаме да експериментираме с различни опции.   -  person wei    schedule 10.08.2012
comment
Ако винаги са едни и същи .h файлове, опитахте ли вече a.o, b.o: h1.h h2.h?   -  person ott--    schedule 10.08.2012
comment
Не винаги са едни и същи .h файлове. това е само пример за илюстрация на въпроса, който имам.   -  person wei    schedule 10.08.2012
comment
ElectricMake и ElectricInsight заедно правят анализа на ефективността на вашия процес на изграждане лесен. Преди да прекарате твърде много време в гледане на strace logs, трябва да опитате и да видите дали може да ви помогне да съсредоточите усилията си върху най-големия, най-ниско висящ плод. electric-cloud.com/products/electricaccelerator-dev.php   -  person Eric Melski    schedule 10.08.2012


Отговори (1)


Използвайте strace за тази цел:

strace -e trace=stat make --touch

Резултат от първото изпълнение (пълно изграждане):

...
stat("a.o", 0x7fff70c35f00)             = -1 ENOENT (No such file or directory)
stat("h1.h", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("h2.h", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
touch a.o
stat("b.o", 0x7fff70c35f00)             = -1 ENOENT (No such file or directory)
touch b.o

И второто изпълнение (постепенно изграждане):

...
stat("a.o", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("h1.h", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("h2.h", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("b.o", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
make: Nothing to be done for `all'.

Както можете да видите, GNU Make кешира времеви отпечатъци, като избягва ненужните stat системни извиквания. Предполагам обаче, че нещата не са толкова добри в случай на използване на рекурсивен make.

person Eldar Abusalimov    schedule 09.08.2012
comment
Благодаря, жалко, имаме рекурсивно създаване, но поне вече знаем, че GNU Make кешира. - person wei; 10.08.2012