makepp_speedup - Online în cloud

PROGRAM:

NUME

makepp_speedup -- Cum să faci makepp mai rapid

DESCRIERE

Deci crezi că makepp este lent? A devenit considerabil mai rapid, dar, desigur, este încă
lent, mai ales dacă vii de la GNU make. Acest lucru se datorează faptului că verifică totul în mod conștiincios
acele lucruri în care gmake îți dă bătăi de cap, ignorând multe dependențe („cred
Trebuie să fac curat pentru a scăpa de un sindrom de bug misterios). Dacă bănuiți că există Perl
codul pe care l-ați adăugat la fișierele dvs. makefile ar putea fi de vină, aruncați o privire la perl_performance.

Dar există câteva lucruri pe care le puteți face pentru a reduce mai multă viteză. Unele lucruri sunt
etichetat ca nesigur, în sensul că îi ceri lui makepp să nu verifice sau să facă anumite lucruri,
despre care crezi că nu sunt necesare. Dacă aceste lucruri ar fi fost necesare, construcția poate
nu fi corect. Din fericire, această problemă va fi însă temporară. Va fi corectat
de îndată ce lași makepp să facă toate verificările.

Puteți combina mai multe dintre aceste sfaturi pentru a crește și mai mult câștigul de timp.

Sigur Aplicate
Utilizare makeppreplay

Utilitarul autonom makeppreplay, mppr repetă lucruri pe care makepp le-a făcut deja,
fără nicio cap de sus.

Utilizare a Mai rapid Perl

În versiunea 5.8, toate sunt aproximativ la fel, doar 5.8.7 este puțin mai rapidă. Reglajul dvs
Perl poate ajuta, de asemenea, cum ar fi să nu îl compilați pentru 64 de biți, de care makepp nu are nevoie. Pentru
exemplu de construcție a ActiveState (http://www.activestate.com/activeperl>) din 5.8.7 pentru Linux
este mai rapid decât Perl 5.8.7 care vine cu SuSE Linux 10.0.

Include as Mic as Posibil

Fiecare fișier suplimentar pe care îl includeți este de două ori penalizator. Pe de o parte, compilatorul trebuie
caută și la toate acele fișiere. Nu observi asta atât de mult, pentru că este doar o
puțin în plus pe apel la compilator. Pe de altă parte, makepp trebuie să caute și el, să găsească
dependențe și să vă dați seama dacă acestea implică o reconstrucție. Atunci poate părea că se blochează,
în timp ce digeră o mulțime de dependențe simultan.

O variantă absolut mortală este fișierul include masterul proiectului, care la rândul său
include în mod convenabil tot ce ai putea avea nevoie. Rezultatul este că orice fișier antet se schimbă
duce la o construcție completă. Chiar și fără o schimbare, makepp trebuie să se gândească la toate aceste anteturi
din nou, pentru fiecare sursă pe care o compilați. Doar un mic efort, deoarece acesta este stocat în cache, dar
mii de fișiere pot face acest lucru uluitor.

Poate fi greoi să vă dați seama setul minim de includeri și să curățați cele nr
este nevoie de mai mult, dar chiar merită. Dacă cineva știe un instrument care poate identifica care
fișierele sunt incluse în mod inutil, aș fi bucuros să menționez acest lucru aici!

Construi as Mic as Tu Nevoie

Dacă aveți o țintă implicită care face mai multe programe, atunci makepp va trebui să verifice
toate dependențele lor, până la cel mai mic fișier antet. Dar poate vrei
testați-vă modificarea doar cu unul dintre aceste programe.

Apoi ai apela makepp cu o țintă explicită. Cu cât mai puține module sau anteturi toate acestea
programele au în comun, cu atât este mai mare beneficiul de a nu lăsa makepp să le verifice pe toate.

Să presupunem că Makeppfile de nivel superior are această regulă:

$(fals toate): proggie1 proggie2 $(only_phony_targets */**/all)

Atunci ai numi lucruri de genul

$ makepp proggie2
$ makepp proggie1 dir/subdir/proggie27

Utilizare preferat makefile nume

Makepp caută fișiere make (cu excepția cazului în care le specificați explicit pe linia de comandă sau cu
„încărcare-makefile”) în ordine RootMakeppfile, RootMakeppfile.mk, Makeppfile și
Makeppfile.mk, urmat de numele clasice de makefile. (Cel .mk variantele sunt pentru pur
sisteme bazate pe sufixe.)

Deci, dacă folosești RootMakeppfile la rădăcina arborelui tău construit și Makeppfile pretutindeni
altfel, fișierele vor fi găsite puțin mai repede. Makepp va avea, de asemenea, un ceva mai mic
consumul de memorie (caching faptul că celelalte nume nu există), ceea ce înseamnă și
viteză prin gestionarea mai puțină a memoriei.

La fel dacă aveți o declarație

include standard

va exista mai întâi o încercare de a găsi standard.makepp, așa că ai putea la fel de bine să folosești asta
nume.

Avea as puțini norme as tu nevoie

Makepp ține evidența nu numai a fișierelor existente, ci și a celor pe care învață să le creeze.
(De aceea oferă wildcards de încredere, cum ar fi *.o.) Prețul pentru această putere este o mulțime de
management. Deci, dacă îi spuneți cum să creați un .o de la un .c, e bine, pentru că va fi
se întâmplă pentru majoritatea, dacă nu pentru toți candidații.

Dar dacă îi spuneți cum să conectați orice executabil fără sufixe de la un asemenea nume .o, asta e
scump, pentru că probabil se va întâmpla doar pentru o mică parte dintre ei (cei care
conțin o funcție principală), dar baza va fi pusă pentru toți. Trebuie să cântăriți
confortul unei reguli de model de linker, față de eficiența regulilor individuale de linker.

Dacă nu folosiți niciuna dintre ele, ar trebui să dezactivați și regulile încorporate cu:

makepp_no_builtin = 1

Dacă le folosiți, dar, din motivele explicate mai sus, nu regulile încorporate de linker,
ar trebui să le dezactivați cu:

makepp_no_builtin_linker = 1

Pune makepp extensii în a modul

Makepp oferă posibilități foarte convenabile de a fi extins prin Perl. Dar daca tu
scrieți unele funcții, comenzi sau instrucțiuni într-un fișier și includeți-le din zeci de
makefiles, veți primi zeci de copii ale tuturor în memorie. Și vor fi citite
de zeci de ori de parserul makepp, care este puțin mai lent decât al lui Perl.

În această situație, este mai bine să vă puneți propriile funcții într-un modul.

Utilizare Repozitorii şi / sau a Construi Cache

Dacă aveți mai mulți dezvoltatori care lucrează pe aceeași mașină sau dacă schimbați încoace și încolo
între seturi de opțiuni de construcție, acesta este pentru tine. Arhivele vă permit să oferiți o centrală
referință în care trebuie doar să construiți ceea ce este diferit la nivel local. Un build cache pur și simplu
colectează toate fișierele produse și le reutiliza după caz, cu mai puțină planificare necesară.
Această din urmă pagină descrie și diferențele.

Utilizare Leagane

Dacă construcția ta este atât de mare încât makepp întâmpină dificultăți în a digera toate informațiile
și dacă puteți găsi o modalitate de a-l împărți în părți independente mai mici, cutii cu nisip
s-ar putea să vă ofere un paralelism mai bun decât opțiunea „--jobs”.

nu face log ceea ce tu do

Caracteristica de logare a lui Makepp este foarte puternică pentru urmărirea erorilor din sistemul de construcție sau
pentru analiza dependențelor dvs. Ori de câte ori nu faceți aceste lucruri, puteți economisi destul de a
bit de formatare și I/O cu „--no-log --no-scan-log”.

Aproape Sigur Aplicate
Obține a Avans

Opțiunea „--loop” (sau „--stop-before-building” sau „--stop-după-încărcare” sau „--stop”)
permite makepp să-și înceapă activitatea în timp ce încă editați. Se va suspenda în mod repetat
în sine când ajunge la punctul de a analiza dependențele. Tu decizi când ești gata
să-l lase mai departe. La proiectul nostru uriaș, acest lucru economisește o jumătate de minut și doar atunci noi
avem un procesor pentru noi înșine.

Această metodă are două dezavantaje potențiale:

· Fișierele Makepp au fost citite până când makepp se oprește. Dacă editați un fișier Makepp sau
ceva din care ar trebui refacut, dupa ce am pornit makepp, asta va merge
neobservată până data viitoare. Dar acest lucru ar trebui să fie rareori necesar, deoarece makepp
reduce foarte mult nevoia de modificări Makeppfile.

· Dacă o țintă depinde de un wildcard și asta se potrivește mai mult decât atunci când Makeppfile
a fost citit, makepp nu va observa:

proggie: *.o
$(LD) $(intrări) -o $(ieșire)

Dacă adăugați un alt fișier sursă sau un fișier din care makepp știe cum să genereze un
sursă, atunci „*.o” ar trebui să se potrivească cu obiectul care produce. Dar, dacă acest fișier a fost adăugat
după ce ai pornit makepp, nu va fi, deoarece wildcard-ul a fost extins prea devreme.

În ambele cazuri, ar trebui să omorâți makepp-ul prepornit și să îl porniți din nou.

Al lui Gulliver Calatorii

Opțiunea „--gullible” îi spune lui makepp să creadă că o regulă schimbă ceea ce spune că va face,
nici mai putin, nici mai mult. Neefectuarea acestor verificări poate economisi câteva procente din CPU-ul makepp
timp. Și economiile de I/O pe disc sunt binevenite în special pe sistemele de fișiere din rețea. Dacă faci
se construiește complet noaptea într-un director gol cu ​​opțiunea „--repository”, dar fără
Opțiunea „--gullible”, puteți fi destul de sigur că setul de reguli este consecvent. Apoi asta
opțiunea nu ar trebui să rănească în munca de zi.

Potenţial nesigur Aplicate
Aceste metode sunt nesigure dacă îi dai lui makepp indicii greșite. Dar totul va fi din nou
bine, totuși, de îndată ce l-ai lăsat pe makepp să facă toate verificările, fără a-i trece nicio limitare
Opțiuni. Din acest motiv, vă sugerez să folosiți aceste sugestii pentru a obține versiuni intermediare rapide,
și folosește ora prânzului și nopțile pentru a-l lăsa pe makepp să-și facă treaba bine.

Construi as Mic as Necesar

Acesta este același sfat de utilizare a țintelor explicite discutat în „Construiți la fel de puțin ca tine
Nevoie" de mai sus. Dar devine mai periculos, dacă o faci pentru că ești sigur că ta
modificarea nu va afecta niciunul dintre celelalte programe. Atunci nici măcar nu vor fi construite
deși ar fi putut fi necesar.

Cunoaște Unde Nu la Construi

Opțiunea „--dont-build” este foarte puternică pentru a accelera mult makepp-ul. Daca stii unul
sau mai multe directoare, despre care sunteți sigur că nu sunt afectate de nicio modificare pe care ați făcut-o de la
ultima dată, puteți emite opțiuni „--dont-build” pentru ei. Acest lucru poate salva makepp o mulțime de
analiza dependenței. Dar nu va construi nimic în acele directoare, chiar dacă
ar trebui sa aiba.

Cunoaște Unde la Construi

Aceasta este la fel cu „Știi unde să nu construiești”, dar în loc de o listă de excludere, tu
furnizați o listă de includere. Trucul este că o opțiune „--do-build”, cu a
opțiunea „--dont-build=/” sau sub un director „RootMakeppfile(.mk)” fără un
Opțiunea „--dont-build” pe un director de nivel superior înseamnă: nu construiți nimic, în afară de ceea ce spun eu
tu să. Acesta este ceea ce caută utilizatorii mărcilor tradiționale atunci când doresc să construiască
un singur director:

$ makepp --do-build=dir/subdir

sau, dacă nu aveți un „RootMakeppfile(.mk)”:

$ makepp --dont-build=/ --do-build=dir/subdir

Diferența este că orice țintă implicită din Makeppfile de nivel superior, adică comenzi de link
sunt de asemenea executate astfel. Dacă nu vrei asta, trebuie să dai o țintă explicită,
care este marcat automat și pentru „--do-build”:

$ makepp --do-build=dir1/subdir dir2/proggie

Cunoaște Ce la Construi

O variantă extremă este să ceri makepp să nu construiască nimic în afară de ceea ce îi spui. Acest
nu este atât de periculos dacă te-ai schimbat Nu. include fișiere, numai module, și știți care
programele în care intră.

Să presupunem că ați schimbat doar „src/a.cpp” și „src/b.cpp” și acestea sunt legate direct în
un singur program. Dot este directorul curent care include toate subdirectoarele.

$ makepp --dont-build=. src/ao src/bo proggie1

Sau echivalent, pentru că o opțiune „--do-build”, fără opțiune „--do-build” pe un
directorul de nivel superior implică „--dont-build” pentru rădăcina arborelui de construcție:

$ makepp --do-build=src/ao src/bo proggie1

Puteți face ceva de genul următor în fișierul $ENV al Shell sau .profile pentru a salva
tastare (utilizatorii csh înlocuiesc „=” cu „ „):

alias mppb='makepp --do-build'
alias mppsb='makepp --stop --do-build'

Apoi ultimul exemplu devine:

$ mppb src/ao src/bo proggie1

Construi on a RAM disc

Calculatoarele moderne, în special serverele, au de obicei un timp mediu mare între defecțiuni. Dacă
acesta este cazul dvs. și aveți o mulțime de memorie RAM de rezervă, vă puteți economisi timp
așteptați I/O. Ar trebui să editați pe un disc real sau să replicați rapid editările acolo. Dar
rezultatele construcției sunt reproductibile, astfel încât acestea pot locui în RAM. Dacă nu vrei să riști
reconstrucție, puteți oricând replica pe disc după fiecare construcție sau noaptea. Tu nu ar trebui să
faceți acest lucru în timpul construirii, deoarece ați putea prinde fișiere parțial scrise, la fel ca și cum ar fi
mașina se prăbușise.

Dacă aveți un sistem și/sau o unitate de stocare cu memorie cache și RAID bune, este posibil ca câștigul să nu fie
atât de mare.

Utilizați makepp_speedup online folosind serviciile onworks.net