English: A speed test for Mercurial and git (in german). -> Links to other tests. Update: I wrote a new test for use in server applications, since they are the only place where a difference of 30-60ms really matters: hg vs. git for server applications.
Ich habe ein paar Testsskripte geschrieben, um die lokale Leistung von Mercurial und GIT vergleichen zu können.
Update: Ich habe einen neuen Test für die Nutzung in Serverprogrammen geschrieben, weil dort der Unterschied um 30-60ms wirklich etwas ausmacht: hg vs. git for server applications.
Was ich wissen wollte ist, wie schnell die Systeme jeweils bei lokalen commits sind (andere Operationen prüfe ich noch nicht), und wie sich ihre Leistung ändert, wenn ich die Anzahl der Dateien oder die Art der Änderungen variiere.
Meine Anregung dafür war der Mercurial-vs-Bazaar Test
Ich nutze selbst fast ausschließlich Mercurial, daher kann es sein, dass ich ein paar Optimierungsmöglichkeiten von git übersehen habe. Ich habe bei Mercurial allerdings auch keine genutzt.
Meine Skripte dazu sind alle in einem Mercurial repository im Netz verfügbar: - http://freehg.org/u/ArneBab/python_tests/
Die Testergebnisse genügen nicht wissenschaftlichen Standards, weil
Bei den Tests war git in den meisten Fällen schneller als Mercurial, vor allem mit wenigen Dateien.
Bei vielen Dateien kam die Geschwindigkeit von Mercurial näher an git heran.
Die Tests, die ich gemacht habe sind:
Bisher hat sich git in Tests mit 2 Dateien als um den Faktor 4 bis 5 schneller erwiesen.
Mit 200 Dateien war es noch um den Faktor 2.5 bis 4 schneller.
Gleichzeitig haben die Daten im Mercurial Ordner nur etwa halb so viel Platz eingenommen, wie in git (ohne repack).
Mit 2000 Dateien war git nur noch um den Faktor 2 bis 2,6 schneller. Das git repo hat dabei knapp 100 MiB belegt hat und das Mercurial repo nur knapp 80 MiB.
Struktur der Ergebnisse: = Für 2 Dateien =
init: - git: 0.01423661708831787 s - Mercurial: 0.13704051971435546 s
initial_commit: - git: 0.086095404624938962s - Mercurial: 0.32350056171417235 s
commit_after_append_small: - git: 0.084930634498596197 - Mercurial: 0.31660361289978028
commit_after_append_of_many_lines: - git: 0.086296844482421878 - Mercurial: 0.31294920444488528
commit_after_append_of_one_long_line: - git: 0.08749730587005615 - Mercurial: 0.32180678844451904
= Für 2000 Dateien =
[git, hg], time in seconds, mean value.
init [0.063668489456176758, 0.14365851879119873] - Factor: 2.25635192571
initial_commit [1.5152170658111572, 3.1502538919448853] - Factor: 2.07907762064
commit_after_append_small [1.4661256074905396, 3.7556029558181763] - Factor: 2.56158335727
commit_after_append_of_many_lines [16.113877415657043, 42.500172019004822] - Factor: 2.63748885031
commit_after_append_of_one_long_line [15.808947086334229, 38.482058048248291] - Factor: 2.43419487953
Anmerkungen:
Use Node:
⚙ Babcom is trying to load the comments ⚙
This textbox will disappear when the comments have been loaded.
If the box below shows an error-page, you need to install Freenet with the Sone-Plugin or set the node-path to your freenet node and click the Reload Comments button (or return).
If you see something like Invalid key: java.net.MalformedURLException: There is no @ in that URI! (Sone/search.html)
, you need to setup Sone and the Web of Trust
If you had Javascript enabled, you would see comments for this page instead of the Sone page of the sites author.
Note: To make a comment which isn’t a reply visible to others here, include a link to this site somewhere in the text of your comment. It will then show up here. To ensure that I get notified of your comment, also include my Sone-ID.
Link to this site and my Sone ID: sone://6~ZDYdvAgMoUfG6M5Kwi7SQqyS-gTcyFeaNN1Pf3FvY
This spam-resistant comment-field is made with babcom.
Zum git gc Problem
Da verfolgt git wirklich einen anderen Anſatz als hg, aber man kann auch da einiges dran drehen (der urſprüngliche Artikel iſt auch ſehr intereſſant, da ſetzt jemand Mercurial ein, um ſein geſamtes Benutzerverzeichnis zu verſionieren :)).
Ich will für Normalnutzung nicht drehen müssen…
Mein Problem mit
git gc
ist, dass ich drehen muss, um ein für die meisten Nutzer sinnvolles Verhalten zu kriegen, und dass häufigeresgc
die Geschwindigkeit beeinträchtigt.Das gilt auch für aliasi (Mercurial bietet per default
hg up
statthg update
, und natürlich kann jeder ein bash alias erstellen, aber es ist nicht per default dabei, so dass die meisten Leute es nicht haben).Die Antwort für die Backup-Lösung (s. dein Link) wäre allerdings eher
hg share
mit einem FUSE ssh mount. Da können dann viele Server das gleiche repo verwenden. Die Schwierigkeit beim backup mit git/Mercurial ist, dass keineDateirechte behalten werden →etckeeper
.PS: Ich wurde von
git gc
leider schon gebissen (wie von einigen anderen Sachen in git). Ich wollte großes cvs repository via cvs2svn undgit fastimport
in git holen, und das git repo wuchs bis meine Platte voll war (ich hatte nicht mehr sehr viel Platz frei, aber noch ein Vielfaches des cvs repos).git & disk usage
On Mai 15th, 2010 Draketo says:
> Ich wollte großes cvs repository via cvs2svn
> und git fastimport in git holen, und das git repo
> wuchs bis meine Platte voll war (ich hatte nicht
> mehr sehr viel Platz frei, aber noch ein Vielfaches
> des cvs repos).
Das liegt daran, daß git erstmal alle Objekte als separate Files speichert (es arbeitet generell immer auf ganzen Bäumen mit kompletten Objekten, und nicht - wie CVS oder SVN mit einer riesengroßen patchqueue), die dann erst später mittels git-gc bzw. git-repack differentiell gepackt werden. Nach dem repack dürfte die Repo idR. sogar ein gutes Stück kleiner sein als im CVS.
Aber warum gehst Du denn den Umweg über cvs2svn ?
Warum nicht gleich git-cvsimport ?
Gruß
Enrico Weigelt, metux IT service
http://www.metux.de/
Kann git-cvsimport ein >5GiB
Kann git-cvsimport ein >5GiB repo importieren (den Gentoo portage tree)?
Woher das Problem kommt weiß ich. Und ich habe eine grundlegende (ästhetische) Abneigung gegen garbage collection, weil damit das Programm bei jedem commit seinen Zustand ändert und sich immer etwas anders verhält (mit auto-gc zeigt es irgendwann plötzlich unerwartete verzögerungen), statt von einem Endzustand in den nächsten überzugehen.
Ich mag es einfach nicht, meine Werkzeuge manuell warten zu müssen, und ich mag kein plötzlich anderes Verhalten (Inkonsistenz: commit, commit, commit, commit, langsamer commit, commit, commit, …). Effektiv ist dadurch das Verhalten von git kontextabhängig: Wie oft habe ich seit dem letzten gc committet?
Trotzdem ist git ein gutes Programm. Es liegt nur für mich deutlich hinter Mercurial.
… und ich auch nicht!
Das iſt witzig – ich dachte, daſs Dir als Gentoo-Nutzer Konfigurationsdateien qaſi ſchon von Natur aus ſympatiſch wären ;). Aber natürlich ſollte eine gute Software auch ſinnvolle Standardwerte mitbringen – wobei ich das für Git durchaus bejahe; ich teile da einfach nicht Deine ſchlechten Erfahrungen, ſondern bin mit dieſer Software ſehr zufrieden. Ich kann aber auch Dich verſtehen; daſs Git bei Dir die Platte geſprengt hat, iſt ziemlich kraſs und ſollte definitiv nicht paſſieren! Witzigerweiſe präferiere ich Git gerade deshalb, weil es im Allgemeinen (allerdings eben erſt nach einem
git gc
!) die kleinſten Dateigrößen für ein Repoſitory produziert. Einigen wir uns darauf, daſs ſich Mercurial und Git ſehr ähnlich ſind und man mit beiden gut und produktiv arbeiten kann :).Ich muſs zu meiner Schande übrigens eingeſtehen, bisher ſo gut wie gar nicht mit Hg gearbeitet zu haben, aber ich habe es mir inzwiſchen inſtalliert :).
Was den Ge-(oder eher Miß-)brauch von Hg und Git für Backupzwecke angeht, so haſt Du mit den felhenden Dateiattributen ein gutes Gegenargument gebracht – aber die Idee an ſich bleibt doch irgendwie beſtechend und verſprüht einfach einen gewiſſen Charme :). Apropros, vielen Dank für den Hinweis auf
etckeeper
, intereſſantes Programm :).configfiles und Mächtigkeit
Ich mag zwar Konfigurationsdateien, in denen ich alles machen kann, was ich will (bieten sowohl git als auch Mercurial), aber ich will nicht reinschauen müssen. Das würde nämlich dazu führen, dass ich in potentiell jedem Programm erst in die config schauen muss. Und ich mag es eigentlich, dass ich die meisten Programme via
emerge programm; forget compile time; programm
nutzen kann.Aber jupp: Mercurial und Git sind sehr ähnlich, und beide haben ihre idealen Anwendungsgebiete.
Nur sehe ich halt Mercurial im Anwendungsgebiet „wir arbeiten mit nicht-codern zusammen“ deutlich vorne (und bei „es soll einfach funktionieren, ohne dass wir viel drüber nachdenken müssen“ ein Stück weit vorne), während git im Gebiet „wir müssen tausende Patches jonglieren“ gewinnt.
Und sowohl git als auch Mercurial können effektiv via hg-git das jeweils andere als Backend-Storage verwenden (nur muss man bei Git halt noch ein Mercurial dazu installieren), was, finde ich, sehr deutlich zeigt, dass sie konzeptuell gleichmächtig sind.
Und für Backups finde ich hg und git auch sehr verlockend. Allerdings bun ich noch nicht dazu gekommen,
etckeeper
zu nutzen. Ich habe zwar /etc unter Versionsverwaltung, aber eigentlich nur, um schauen zu können, wann ich was wie geändert habe (usecase: „verdammt, es tut nicht mehr! Was habe ich denn verändert?“). Das ist übrigens auch der erste usecase, den ich im Mercurial Guide geschrieben habe :)