Importgeschwindigkeit: GSAK vs. OCM

Eines der größten Probleme von OpenCacheManager war bisher immer die Geschwindigkeit. Dies betraf zum Einen die Geschwindigkeit mit der die Datensätze gefiltert wurden, zum Anderen aber auch die Geschwindigkeit mit der neue Daten importiert wurden. So wurde davon berichtet, das 12 volle PQs mal eben 20 Minuten für den Import in Anspruch nahmen. Dies bezog sich zwar auf eine Vorabversion und ich selbst konnte das so nicht nachvollziehen, aber dennoch nahm ich das zum Anlaß den Import mit der aktuellen Version zu testen, die ja bekanntlich auf allen Ebenen in Sachen Geschwindigkeit zugelegt hat. Als Vergleichskandidaten zog ich GSAK heran. Das ist allerdings kein sehr exakter Vergleich, denn GSAK erfordert Windows, welches hier nur auf einer  virtuellen Maschine installiert ist.

Ich begann mit GSAK und startete die virtuelle Maschine ganz frisch, legte dann sicherheitshalber alle Prozesse lahm die sich negativ auf die Geschwindigkeit auswirken könnten und begann zu warten. Das war nötig, denn ich habe GSAK vor 177 Tagen auf dieser Maschine installiert. Dies wird als komplette Benutzungszeit angenommen, wenngleich es real nur wenige Tage Test waren, die ich dann aber irgendwann aufgab, da GSAK mit steigendem Datenbestand einfach zu zäh lief. Naja, und wenn man mit steigender Benutzungszeit immer längere Nervmeldungen bekommt, dann ist das auch nicht gerade fein, die 140 Sekunden die mich GSAK inzwischen bei jeder Kleinigkeit warten lässt schlagen dem Faß dann endgültig den Boden aus. Benutzerunfreundlicher geht es kaum, aber so ist das eben mit Nagware. Aber das soll hier nicht Gegenstand sein, wir wollen ja Daten importieren.

Zunächst startete ich einen Import in eine Datenbank, in der sich knappe 10.000 Caches befanden. Die zu importierenden PQs, eine MyFinds und 5 „gewöhnliche“, hatten reichlich neues Material dabei. GSAK legte los und hatte nach Import der MyFinds mit 2061 Caches Umfang knappe 4 Minuten auf der Uhr. Die 5 PQs nebst zusätzlichen Wegpunkten gingen dann etwas schneller und nach 8 Minuten und 36 Sekunden blieb der Zeiger der Stoppuhr stehen. 472 Caches und 241 zusätzliche Wegpunkte waren neu für GSAK, der Rest bekannt. Dennoch fand ich die zeit recht heftig, also nahm ich nochmal eine frisch angelegte, blitzeblanke Datenbank daher und importierte erneut. Diesmal blieb der Zeiger schon nach 1 Minute und 54 Sekunden stehen. GSAK hatte danach 7061 Caches und 2226 zusätzliche Wegpunkte importiert.

Nun war OCM an der Reihe. Da OCM ja nicht auf der virtuellen Maschine rennt, musste die echte Maschine etwas beschäftigt werden um hier keine allzu großen Vorteile zu haben. Also startete ich neben der schon laufenden virtuellen Windowskiste noch einen virtuellen Linuxserver um auf diese Weise RAM und Prozessor ein wenig zu beschäftigen. Das schafft zwar nicht wirklich identische Verhältnisse, aber die ganze Geschichte erhebt ja keinen Anspruch auf Professionalität, es ist eher ein Hausgebrauchsvergleich.

Wie dem auch sei, OCM wurde gestartet und durfte ebenfalls die 6 Dateien importieren. Das heißt, wie auch schon GSAK, entpacken und die daraus resultierenden 11 Dateien importieren. Während des Entpackens zeigte sich OCM von der spaßigen Seite und kümmerte sich zunächst um „File blah of blah“ bevor es richtig losging. *gg* Das war mir bisher noch gar nicht aufgefallen, denn ich importiere die PQs gewöhnlich tagfertig, so das es immer maximal 3 Stück sind und die sind so fix abgefertigt, das mir das bisher nie aufgefallen ist. Allerdings brauchte ich auch heute trotz der 6 PQs mehrere Anläufe bis der Screenshot gelang. Wie dem auch sei, OCM beackerte die Dateien und nach sagenhaften 51 Sekunden waren alle Daten importiert und dabei 9412 Caches und andere Wegpunkte verarbeitet. Da war ich baff!

In der Datenbank von OCM befanden sich vorher übrigens knappe 12.000 Caches, also 2.000 mehr als in der GSAK-Datenbank, aber da OCM ja den Vorteil von mehr Arbeitsspeicher hatte passt das schon. Auf einen Test mit einer leeren Datenbank habe ich dann übrigens verzichtet, schließlich war das Ergebnis des ersten Laufes schon zufriedenstellend genug.

Schrottie

Ich blogge hier seit Anfang 2005 über wechselnde Themen. Zumeist handelt es sich dabei um Linux, Android, Geocaching oder Fotografie, aber zunehmend auch rund ums Fahrradfahren (mit MTB und Rennrad), das ich nach einigen Jahren Pause wieder für mich entdeckt habe. Dabei ist die Themenwahl insgesamt recht selektiv, also ich schreibe immer nur dann, wenn mich etwas wirklich interessiert und/oder bewegt und so kommt es dann auch, das man hier zuweilen auch private Dinge findet. Wer mir für die Arbeit ein kleines Dankeschön zukommen lassen möchte, der kann dies gern über meinen Amazon Wunschzettel tun. :-)

9 thoughts to “Importgeschwindigkeit: GSAK vs. OCM”

  1. Ja, seit dem neuen Release ist OCM wesentlich schneller geworden!
    Den Verweis auf die GSAK-Nagscreens finde ich nicht ganz gerecht – ja, OCM ist open source und (noch? Ich habe Kyle noch nie darauf angesprochen) kostenfrei, GSAK ist aber auch jeden Dollar wert – es ist immer noch die Referenz. Dann „naggt“ nichts mehr!

    1. Deswegen schrieb ich ja dazu, das es Nagware ist. Ein Vertriebsmodell übrigens, das mir so ganz und gar nicht gefällt. Ich hatte GSAK ja bspw. irgendwann mal installiert und kam dann nicht zum testen. Als es dann soweit war, lag der Nagscreen schon bei 1 Minute. Und wenn ich bei jedem bißchen erstmal eine, oder jetzt schon über zwei Minuten lesen muss, das ich das Programm doch gefälligst kaufen soll, dann finde ich das eben nicht nett, Referenzsoftware hin oder her. Dem Vernehmen nach ist GSAK ja wirklich eine tolle Sache, aber eben aus Gründen der pausenlosen Warterei kann ich das nicht so genau abschätzen, testen ist damit ja nahezu unmöglich. Aber ich brauche es ja auch nicht, denn zum Glück gibt es OCM. 🙂

  2. Sag mal, gibts da auch eine handliche Windows-install-exe, oder mach ich was falsch. Ich sehe beim download nur eine Haufen dateien. 🙁

  3. Nee, bisher gibt es keine Windows Version von OCM. Ich denke das ist nicht unmöglich, bisher hat sich aber auch noch niemand daran gemacht. Aber wenn jemand Erfahrung darin hat Monoprogramme inkl. Abhängigkeiten unter Windows zum laufen zu bekommen kann er sich gerne freiwillig melden 😉

    Also bisher brauchst du ein Linux System, eine Virtuelle Maschine sollte da völlig ausreichen. Am besten darin Ubuntu installieren, denn die Pakete scheinen bisher zuverlässig zu funktionieren.

  4. Nach dem „File blah of blah“ muss Kyle mal schauen – das sieht nach hartkodierten Überresten im Code aus. In der Übersetzungsdatei ist das nicht enthalten.
    Willst Du den Bug einstellen oder soll ich? :silly:

    1. @sep. Ist doch kein Problem. Auch Linux kriegst Du in allen nur erdenklichen Varianten kostenlos und ganz legal zum Download. Einfach herunterladen, installieren und glücklich sein. 🙂

Kommentare sind geschlossen.