Hase vs. Igel: Git und SVN im Magento-Performancetest

Ich beschäftige mich in letzter Zeit verstärkt mit Git. Da man immer hört, dass Git Subversion in der Geschwindigkeit weit überlegen ist, dachte ich mir, ich starte einen informellen Test und kontrolliere, wie sich die zwei Versionierungssysteme mit einer Codebasis in der Größenordnung meines Liebkinds Magento verhalten.

Rechner-Konfiguration

Zum Einsatz kommt eine virtuelle Maschine in VirtualBox mit 1 Core (Intel Q6600 @ 2.40 Ghz) und 1536 MB RAM. Darauf läuft eine Grundinstallation von Debian Squeeze mit der benötigten Software in der aktuellen Version. Die Repositories und die Arbeitskopien liegen auf derselben Maschine. Ich verwende Magento 1.5.1.0 von der Website.

Setup

Ich lade die Archiv-Datei, entpacke das Archiv in die Verzeichisse und erstelle die (leeren) Repositories für Git und SVN:

Initialer Commit

Jetzt kann es losgehen – wir fügen die gesamte Ordnerstruktur hinzu und stoppen die Zeit mit „time“. In der Praxis wird man je nach Gusto nur einen Teil der Dateien versionieren, aber mir geht’s jetzt nur um die Geschwindigkeit.

Die Befehle für SVN:

Die Befehle für Git:

Ergebnisse

SVNZeit (sek)GitZeit (sek)
svn add *18.09 sgit add *27.26 s
svn status1.98 sgit status0.62 s
svn commit -m "Initial commit"116.78 sgit commit -m "Initial commit"12.92 s

Die Ergebnisse sprechen für sich. Git ist beim Hinzufügen der Dateien um ca. 50 Prozent langsamer, lässt SVN bei der Status-Abfrage und den Commit aber weit hinter sich: die Status-Abfrage ist gut 3-mal so schnell, der Commit wird 9-mal so schnell erledigt. Vor allem der Status und der Commit sind interessant, da nur relativ selten große Dateimengen hinzugefügt, dieser aber dafür umso häufiger geändert werden.

Wer nicht mit Magento arbeitet, wird sich für den Umfang der Codebasis interessieren: es handelt sich bei Magento 1.5.1.0 um 3.735 Ordner und 10.490 Dateien, die laut Debian 103 MB belegen.
(Den Aufmerksamen wird aufgefallen sein: mit den obigen Befehlen werden .htaccess und .htaccess.sample im Root-Verzeichnis nicht versioniert, also sind eigentlich 2 Dateien weniger versioniert. ;))

Checkout

Ein weiteres Szenario ist der Checkout des Codes aus dem bestehenden Repository.

Der Befehl für SVN:

Der Befehl für Git:

Ergebnisse

SVNZeit (sek)GitZeit (sek)
svn checkout file:///var/svn/repos/vcstest svn-checkout54.44 sgit clone git git-checkout27.51 s

Auch hier ist Git doppelt so schnell. Wenn man mit vielen Arbeitskopien arbeitet, kann das ein wichtiger Faktor sein.

Commit von Änderungen

Was wäre eine Versionskontrolle ohne Änderungen? Genau: nichts. Deswegen überprüfe ich als nächstes die Performance, wenn sich viele Dateien geändert haben. Für die Manipulation der Files verwende ich diesen Befehl:

Damit wird jeder Datei, die nicht leer ist, in der ersten Zeile der Text „second commit“ eingefügt. In Magento gibt es rund ein dutzend leere Dateien. SVN und Git werden also an Änderungen in ~ 10.480 Dateien zu kauen haben.

Die Befehle für SVN:

Die Befehle für Git:

Ergebnisse

SVNZeit (sek)GitZeit (sek)
svn status1.68 sgit status1.57 s
svn commit -m "Second commit"126.12 sgit commit -a -m "Second commit"25.2 s
svn update94.77 sgit pull /var/www/git master16.76 s

Auch hier glänzt Git – während sich die Tools beim Status nichts nehmen, ist Git beim Commit 5-mal schneller und benötigt beim Update der zweiten Arbeitskopie weniger als ein Fünftel der Zeit.

Fazit

Git ist wirklich verdammt schnell. Im Webentwickler-Alltag wird man nicht ununterbrochen große Dateimengen ein- und auschecken, doch die Vielzahl kleinerer Änderungen summiert sich ebenfalls. Nicht zu unterschätzen ist, dass die bessere Reaktionszeit von Git motiviert und einlädt, Versionierung umfassend zu verwenden, anstatt nur hier und da damit zu arbeiten. Zudem hat sich das Mergen (Zusammenführen) von großen Changeset bei Subversion leider als fragil erwiesen, was mitunter zu größberen Reperaturarbeiten führt. Ein Like für Git!

7 Antworten

  1. Daniel Lang sagt:

    Du hast einen ganz wichtigen Benchmark vergessen 😉 – die Entwicklerzeit die es braucht um einen simplen Tree-Conflict in SVN aufzulösen.

    Folgendes (für agile Entwicklerteams nicht seltene) Szenario:
    Entwicker 1 und Entwickler 2 arbeiten am selben Projekt. Beide machen einen Checkout. Entwickler 1 fügt in den Ordner A ein paar Dateien hinzu und ändert ein paar. Entwickler 2 macht ein bisschen Refactoring und verschiebt Ordner A in den Ordner B. Entwickler 2 macht einen Commit. Entwickler 1 macht ein Update, damit er danach auch ein Commit machen kann -> BOOM! Es folgt eine undefinierte Arbeitszeitverweschendung des SVN-Entwicklers umd den Tree-Conflict aufzulösen, während der Git-Entwickler gar nichts merkt und schon am nächsten Feature bastelt…

  2. Andreas Krey sagt:

    ‚git add .‘ hätte die .htaccess-Dateien auch mitgenommen, derweil ’svn add .‘ nur „svn: warning: ‚.‘ is already under version control“ murmelt, und svn stellt sich in vielen Dingen so dämlich an.

    Für simple Merges in großen Repositories habe ich auch schon Zeitverhältnisse von 300:1 (svn:git) beobachtet. Ganz zu schweigen von solchen Dummerhaftigkeiten, daß *jedes* svn-Kommando, das mit dem Repository spricht, plötzlich 15 Sekunden braucht, wenn man per GPRS angebunden ist.

  3. Heiko sagt:

    ssiaiiza rdie Uneschedlichen Zeiten beim Status-Kmndo zegen dass de Messergebnsse nict robut eidsin. Wnndasgleice Kommando mal 1/3 undmal degec Zeit brauht Aßerdm muss man aberwähne, das Git duch die vereiltn Repositores gnz andere Arbeitsprozesse erlaut -zB. das lokle .linvveature bevor e aderen Entwicklern bereitgestelt wird.

    • Hallo Heiko,
      es handelte sich nur um einen informellen Test. Daher hast du recht: robust im eigentlichen Sinn die Ergebnisse nicht. In der Praxis ist es auf jeden Fall so, dass Git wesentlich flotter arbeitet.
      Die verteilte Entwicklung ist ebenfalls eine feine Sache. Die größte Änderung bei unseren Arbeitsprozessen ist aber, dass für jede Aufgabe (außer vielleicht für ganz kleine) ein eigener Issue-Branch erstellt wird. Da alles schnell und verlässlich funktioniert, ist die Akzeptanz für diese Vorgehensweise viel größer als früher bei SVN.

  1. 15.08.2011

    […] hat sich gezeigt, dass Git wesentlich schneller als SVN ist. Vor einigen Wochen habe ich einen Geschwindigkeitstest von Git und SVN mit Magento durchgeführt, in dem ihr das nachlesen könnt.LesematerialIch habe bisher zwei Bücher zu Git […]