makepp_speedup - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

makepp_speedup -- Wie man Makepp schneller macht

BESCHREIBUNG

Du denkst also, Makepp ist langsam? Es ist merklich schneller geworden, aber zugegeben, es ist immer noch
langsam, besonders wenn Sie von GNU make kommen. Dies liegt daran, dass es gewissenhaft alle überprüft
diese Dinge, bei denen gmake Kopfschmerzen bereitet und viele Abhängigkeiten ignoriert (das "Ich denke
Ich muss sauber machen, um ein mysteriöses Bug"-Syndrom loszuwerden).
Code, den Sie zu Ihren Makefiles hinzugefügt haben, könnte fehlerhaft sein, werfen Sie einen Blick auf perl_performance.

Aber es gibt ein paar Dinge, die Sie tun können, um mehr Geschwindigkeit herauszuholen. Einige der Dinge sind
als unsicher gekennzeichnet, da Sie Makepp auffordern, bestimmte Dinge nicht zu überprüfen oder zu tun,
die Ihrer Meinung nach nicht benötigt werden. Wenn diese Dinge notwendig gewesen wären, könnte der Build
nicht richtig sein. Glücklicherweise wird dieses Problem jedoch vorübergehend sein. Es wird korrigiert
sobald Sie makepp alle Prüfungen durchführen lassen.

Sie können mehrere dieser Tipps kombinieren, um den Zeitgewinn noch weiter zu steigern.

Sicher Methoden
Verwenden Sie die makepppreplay

Das eigenständige Dienstprogramm makeppreplay, mppr wiederholt Dinge, die makepp bereits getan hat,
ohne Mehraufwand.

Verwenden Sie die a Schneller Perl

In Version 5.8 sind alle ungefähr gleich, nur 5.8.7 ist etwas schneller. Tune dein
Perl kann auch helfen, zum Beispiel, es nicht für 64 Bit zu kompilieren, was makepp nicht braucht. Zum
Beispiel ActiveState Build (http://www.activestate.com/activeperl>) von 5.8.7 für Linux
ist schneller als das mit SuSE Linux 5.8.7 gelieferte Perl 10.0.

Umfassen as Wenig as Möglich

Jede zusätzliche Datei, die Sie einschließen, wird doppelt bestraft. Einerseits muss der Compiler
Suchen Sie nach und in all diesen Dateien. Das merkt man nicht so sehr, denn es ist nur a
wenig extra pro Compileraufruf. Andererseits muss makepp auch suchen, um zu finden
Abhängigkeiten und finden Sie heraus, ob sie einen Neuaufbau erfordern. Dann scheint es zu stehen,
während es viele Abhängigkeiten auf einmal verdaut.

Eine absolut tödliche Variante ist die Projekt-Master-Include-Datei, die wiederum
enthält bequem alles, was Sie benötigen. Das Ergebnis ist, dass sich jede Header-Datei ändert
führt zu einem vollständigen Build. Auch ohne Änderung muss makepp an all diese Header denken
wieder für jede Quelle, die Sie kompilieren. Nur ein winziger Aufwand, da dies zwischengespeichert ist, aber
Tausende von Dateien können dies atemberaubend machen.

Es kann mühsam sein, den minimalen Satz von Einschlüssen zu ermitteln und diese nicht zu bereinigen
länger benötigt, aber es zahlt sich wirklich aus. Falls jemand ein Tool kennt, das erkennen kann, welches
Dateien werden unnötigerweise eingebunden, das erwähne ich gerne hier!

Bauen as Wenig as Du Need

Wenn Sie ein Standardziel haben, das mehrere Programme erstellt, muss makepp überprüfen
alle ihre Abhängigkeiten, bis hin zur kleinsten Header-Datei. Aber vielleicht willst du
Testen Sie Ihre Änderung mit nur einem dieser Programme.

Dann würden Sie makepp mit einem expliziten Ziel aufrufen. Je weniger Module oder Header all dies
Programme gemeinsam haben, desto größer ist der Vorteil, dass makepp sie nicht alle überprüfen lässt.

Angenommen, Ihr Makeppfile auf oberster Ebene hat diese Regel:

$(falsche alle): proggie1 proggie2 $(only_phony_targets */**/all)

Dann würdest du Dinge nennen wie

$ makepp proggie2
$ makepp proggie1 Verzeichnis/Unterverzeichnis/proggie27

Verwenden Sie die bevorzugt Makefile Namen

Makepp sucht nach Makefiles (es sei denn, Sie geben sie explizit in der Befehlszeile oder mit . an
"load-makefile") in der Bestellung RootMakeppfile, RootMakeppfile.mk, Makeppfile und
Makeppfile.mk, gefolgt von den klassischen Makefile-Namen. (Die .mk Varianten sind für rein
suffixbasierte Systeme.)

Also, wenn Sie verwenden RootMakeppfile an der Wurzel Ihres Build-Baums, und Makeppfile überall
Andernfalls werden die Dateien etwas schneller gefunden. Makepp wird auch ein etwas kleineres haben
Speicherverbrauch (zwischenspeichern der Tatsache, dass die anderen Namen nicht existieren), was auch bedeutet:
Geschwindigkeit durch weniger Speicherverwaltung.

Ebenso, wenn Sie eine Aussage haben

Standard einschließen

es wird zuerst versucht zu finden standard.makepp, also kannst du das genauso gut verwenden
Namen.

Haben as wenige Ohne eine erfahrene Medienplanung zur Festlegung von Regeln und Strategien beschleunigt der programmatische Medieneinkauf einfach die Rate der verschwenderischen Ausgaben. as U technische

Makepp verfolgt nicht nur vorhandene Dateien, sondern auch alle, die es zu erstellen lernt.
(Deshalb bietet es zuverlässige Wildcards wie *.Ö.) Der Preis für diese Leistung ist viel
Verwaltung. Also, wenn du ihm erzählst, wie man a . erstellt .o von einem .c, das ist in Ordnung, denn es wird
passieren für die meisten, wenn nicht alle Kandidaten.

Aber wenn Sie ihm sagen, wie man eine suffixlose ausführbare Datei von einem ähnlichen Namen verknüpft .o, das ist
teuer, weil es wahrscheinlich nur bei einem kleinen Teil von ihnen passieren wird (die, die
eine main-Funktion enthalten), aber die Basis wird für alle gelegt. Du musst das wiegen
Komfort einer Linker-Musterregel gegen die Effizienz einzelner Linker-Regeln.

Wenn Sie keine davon verwenden, sollten Sie auch die integrierten Regeln deaktivieren mit:

makepp_no_builtin = 1

Wenn Sie sie verwenden, aber aus den oben genannten Gründen nicht die eingebauten Linker-Regeln,
diese solltest du ausschalten mit:

makepp_no_builtin_linker = 1

setzen machenpp Erweiterungen in a Modulen

Makepp bietet sehr bequeme Möglichkeiten der Erweiterung durch Perl. Aber wenn du
schreibe einige Funktionen, Befehle oder Anweisungen in eine Datei und füge diese aus Dutzenden von
makefiles, erhalten Sie Dutzende von Kopien davon alle im Speicher. Und sie werden gelesen
Dutzende Male durch den makepp-Parser, der etwas langsamer ist als der von Perl.

In dieser Situation ist es besser, eigene Funktionen in einem Modul unterzubringen.

Verwenden Sie die Aufbewahrungsorte und / oder a Bauen Cache

Wenn mehrere Entwickler an derselben Maschine arbeiten oder wenn Sie hin und her wechseln
zwischen Sätzen von Build-Optionen ist dies für Sie. Mit Repositories können Sie eine zentrale
Referenz, wo Sie nur bauen müssen, was lokal anders ist. Einfach ein Build-Cache
sammelt alle produzierten Dateien und verwendet sie bei Bedarf wieder, mit weniger Planungsaufwand.
Auf der letzten Seite werden auch die Unterschiede beschrieben.

Verwenden Sie die Sandkästen

Wenn Ihr Build so groß ist, dass es Makepp schwer fällt, alle Informationen zu verdauen
und wenn Sie eine Möglichkeit finden, es in kleinere unabhängige Teile aufzuteilen, Sandboxen
könnte Ihnen eine bessere Parallelität bieten als die Option "--jobs".

Nicht Log was U do

Die Protokollierungsfunktion von Makepp ist sehr mächtig, um Fehler im Build-System aufzuspüren, oder
zur Analyse Ihrer Abhängigkeiten. Wenn Sie diese Dinge nicht tun, können Sie eine Menge sparen
etwas Formatierung und I/O mit "--no-log --no-scan-log".

Fast Sicher Methoden
Erhalten Sie a Vorsprung

Die Option "--loop" (oder "--stop-before-building" oder "--stop-after-loading" oder "--stop")
ermöglicht es makepp, mit der Arbeit zu beginnen, während Sie noch bearbeiten. Es wird wiederholt ausgesetzt
sich selbst, wenn es zur Analyse der Abhängigkeiten kommt. Du entscheidest wann du bereit bist
es weitergehen zu lassen. Bei unserem Riesenprojekt spart das eine halbe Minute, und das nur, wenn wir
eine CPU für uns haben.

Diese Methode hat zwei potenzielle Nachteile:

· Makeppfiles wurden gelesen, bis makepp stoppt. Wenn Sie ein Makeppfile bearbeiten oder
etwas, aus dem es neu aufgebaut werden müsste, nach dem Starten von makepp wird das gehen
unbemerkt bis zum nächsten mal. Dies sollte aber selten nötig sein, da makepp
reduziert den Bedarf an Makeppfile-Änderungen erheblich.

· Wenn ein Ziel von einem Platzhalter abhängt, und das würde mehr übereinstimmen, als wenn das Makeppfile
gelesen wurde, wird makepp nicht bemerken:

Programm: *.o
$(LD) $(Eingaben) -o $(Ausgaben)

Wenn Sie eine weitere Quelldatei hinzufügen, oder eine Datei, aus der makepp weiß, wie ein
source, dann sollte "*.o" mit dem Objekt übereinstimmen, das erzeugt. Aber wenn diese Datei hinzugefügt wurde
nach dem start von makepp geht es nicht, weil der Platzhalter zu früh erweitert wurde.

In beiden Fällen sollten Sie das vorab gestartete Makepp beenden und neu starten.

Gullivers Reisen

Die Option "--gullible" weist makepp an zu glauben, dass eine Regel ändert, was sie sagt.
weder weniger noch mehr. Wenn diese Überprüfungen nicht durchgeführt werden, können einige Prozent der CPU von makepp eingespart werden
Zeit. Und die Disk-I/O-Einsparungen sind besonders bei Netzwerkdateisystemen willkommen. Wenn Sie tun
nächtliche vollständige Builds in einem leeren Verzeichnis mit der Option "--repository", jedoch ohne die
Mit der Option "--gullible" können Sie ziemlich sicher sein, dass Ihr Regelsatz konsistent ist. Dann das
Option sollte bei Ihrer Tagesarbeit nicht schaden.

Möglicherweise Unsicher Methoden
Diese Methoden sind unsicher, wenn Sie makepp die falschen Hinweise geben. Aber alles wird wieder sein
Gut, aber sobald Sie makepp alle Prüfungen durchführen lassen, indem Sie es nicht einschränken
Optionen. Aus diesem Grund schlage ich vor, diese Hinweise zu verwenden, um schnelle Zwischenbuilds zu erhalten.
und nutze die Mittags- und Nachtzeit, um makepp seine Arbeit gründlich erledigen zu lassen.

Bauen as Wenig as Benötigte

Dies ist derselbe Tipp zur Verwendung expliziter Ziele, der unter „Bauen Sie so wenig wie Sie“ beschrieben wurde
Need" oben. Gefährlicher wird es aber, wenn Sie es tun, weil Sie sicher sind, dass Ihr
Die Änderung wirkt sich nicht auf die anderen Programme aus. Dann werden sie auch nicht gebaut
obwohl es vielleicht nötig gewesen wäre.

Wissen Wo Sie hilft nicht nur zu Bauen

Die Option "--dont-build" ist sehr mächtig, um das Make-up stark zu beschleunigen. Wenn du einen kennst
oder mehrere Verzeichnisse, von denen Sie sicher sind, dass sie von Änderungen, die Sie seit dem
Beim letzten Mal können Sie "--dont-build"-Optionen für sie ausgeben. Das kann Makepp viel sparen
Abhängigkeitsanalyse. Aber es wird nichts in diesen Verzeichnissen erstellen, selbst wenn es
sollte haben.

Wissen Wo zu Bauen

Dies ist dasselbe wie "Wissen, wo nicht gebaut werden soll", aber anstelle einer Ausschlussliste
eine Aufnahmeliste liefern. Der Trick besteht darin, dass eine Option "--do-build" mit a
Option "--dont-build=/" oder in einem Verzeichnis "RootMakeppfile(.mk)" ohne a
Die Option "--dont-build" in einem Verzeichnis auf höherer Ebene bedeutet: nichts bauen, außer was ich erzähle
Du auch. Das suchen Nutzer traditioneller Fabrikate, wenn sie bauen wollen
nur ein Verzeichnis:

$ makepp --do-build=dir/subdir

oder, wenn Sie kein "RootMakeppfile(.mk)" haben:

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

Der Unterschied besteht darin, dass jedes Standardziel im Makeppfile der obersten Ebene, dh Linkbefehle
werden auch so ausgeführt. Wenn Sie das nicht möchten, müssen Sie ein explizites Ziel angeben,
die automatisch auch für "--do-build" markiert ist:

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

Wissen Was zu Bauen

Eine extreme Variante besteht darin, makepp aufzufordern, nichts anderes zu bauen, als das, was Sie ihm sagen. Dies
ist nicht so gefährlich wenn man sich verändert nicht das Dateien, nur Module, und Sie wissen welche
Programme, in die sie einsteigen.

Angenommen, Sie haben nur "src/a.cpp" und "src/b.cpp" geändert und diese sind direkt verlinkt in
ein Programm. Punkt ist das aktuelle Verzeichnis inklusive aller Unterverzeichnisse.

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

Oder entsprechend, weil eine "--do-build"-Option ohne eine "--dont-build"-Option auf a
Verzeichnis der höheren Ebene impliziert "--dont-build" für die Wurzel des Build-Baums:

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

Sie können in der $ENV-Datei oder .profile Ihrer Shell Folgendes tun, um zu speichern
Eingabe (csh-Benutzer ersetzen '=' durch ' '):

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

Dann wird das letzte Beispiel:

$ mppb src/ao src/bo proggie1

Bauen on a RAM Scheibe

Moderne Computer, insbesondere Server, haben typischerweise eine hohe mittlere Zeit zwischen Ausfällen. Wenn
Dies ist bei Ihnen der Fall, und Sie haben viel RAM übrig, Sie können die Zeit sparen, die Sie haben
warte auf E/A. Sie sollten auf einer echten Festplatte bearbeiten oder Ihre Änderungen dort schnell replizieren. Aber
Die Build-Ergebnisse sind reproduzierbar, sodass sie sich im RAM befinden können. Wenn du kein Risiko eingehen willst
Wiederherstellung können Sie nach jedem Build oder nachts immer auf die Festplatte replizieren. Du solltest nicht
Tun Sie dies während des Builds, da Sie möglicherweise teilweise geschriebene Dateien abfangen, als ob die
Maschine war abgestürzt.

Wenn Sie ein System und/oder eine Speichereinheit mit gutem Caching und RAID haben, ist der Gewinn möglicherweise nicht
so groß.

Verwenden Sie makepp_speedup online mit den onworks.net-Diensten