-
Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.
CB 520 / CB 533 mit DB 3.5
- Ersteller Inder
- Erstellt am
hanknstone
Geocacher
moin moin ...
Da habe ich ein ähnliches Erscheinungsbild .... vor der SQL-Umstellung brauchte CB ´ne gefühlte halbe Minute zum Starten... momentan dauerts (bei schlappen 2000 Caches in der DB) gute 4-5 Minuten....
(Gerät: HTC Touch 2)
----------
Nachtrag: so, und jetzt etwas genauer, mit der eben aus dem heutigen SVN compilierten CB Version 550... und einer identischen DB (1980 Dosen, ca 45MB Daten) auf den Geräten, benötigt bei mir der Start der DB auf:
HTC Touch 2 - 2 Minuten
MDA Compact V - 1 Minute 45 Sekunden .
Wobei klar sein sollte, das der MDA Compact V das ältere und auch leistungsschwächere Gerät ist...
Ich bin erstaunt. Mag sein das die unterschiedlichen Windows Mobile Versionen (6.5 / 6.1) einen Einfluss haben... aber erklären kann ich´s mir nicht das der alte MDA schneller ist..
Egal, gefühlt langsamer sind die neuen Versionen allemale (ich hatte das auf mein selbsterstellen geschoben), ich kann aber damit leben .... mann muss nur sein Gerät frühzeitig starten wenn mann auf Tour geht :->
Da habe ich ein ähnliches Erscheinungsbild .... vor der SQL-Umstellung brauchte CB ´ne gefühlte halbe Minute zum Starten... momentan dauerts (bei schlappen 2000 Caches in der DB) gute 4-5 Minuten....
(Gerät: HTC Touch 2)
----------
Nachtrag: so, und jetzt etwas genauer, mit der eben aus dem heutigen SVN compilierten CB Version 550... und einer identischen DB (1980 Dosen, ca 45MB Daten) auf den Geräten, benötigt bei mir der Start der DB auf:
HTC Touch 2 - 2 Minuten
MDA Compact V - 1 Minute 45 Sekunden .
Wobei klar sein sollte, das der MDA Compact V das ältere und auch leistungsschwächere Gerät ist...
Ich bin erstaunt. Mag sein das die unterschiedlichen Windows Mobile Versionen (6.5 / 6.1) einen Einfluss haben... aber erklären kann ich´s mir nicht das der alte MDA schneller ist..
Egal, gefühlt langsamer sind die neuen Versionen allemale (ich hatte das auf mein selbsterstellen geschoben), ich kann aber damit leben .... mann muss nur sein Gerät frühzeitig starten wenn mann auf Tour geht :->
GeoSilverio
Geowizard
Ja, irgendwas hakt da noch...
Mit der 517er hatte ich einen vollständigen CB-Start in 15 oder 20 Sekunden oder so.
Mit der 533er dauert es fast 1,5 Minuten.
Etwas über 5000 Caches auf dem HD2
Es dauert an der Stelle lang, an der unten in der Statuszeile "Loading Caches..." steht, also ganz zum Ende des Startvorganges.
Der Sort der Datenbank kann es eigentlich nicht sein, da jeder resort dann später manuell nur Sekunden dauert.
Es muss aber wohl schon grundsätzlich mit der DB zu tun haben, denn eine leere oder kleine DB (mit 280 Caches getestet), geht ganz normal auf.
Mit der 517er hatte ich einen vollständigen CB-Start in 15 oder 20 Sekunden oder so.
Mit der 533er dauert es fast 1,5 Minuten.
Etwas über 5000 Caches auf dem HD2
Es dauert an der Stelle lang, an der unten in der Statuszeile "Loading Caches..." steht, also ganz zum Ende des Startvorganges.
Der Sort der Datenbank kann es eigentlich nicht sein, da jeder resort dann später manuell nur Sekunden dauert.
Es muss aber wohl schon grundsätzlich mit der DB zu tun haben, denn eine leere oder kleine DB (mit 280 Caches getestet), geht ganz normal auf.
millimeterfuchser
Geocacher
Also ich hätte da folgende Werte anzubieten bei ca. 2700 Einträgen:
CB520 MDA Vario @ 195 Mhz : 2Min 20Sek
CB520 MDA Vario @ 264 Mhz: 1Min 40Sek
Gruß, André
CB520 MDA Vario @ 195 Mhz : 2Min 20Sek
CB520 MDA Vario @ 264 Mhz: 1Min 40Sek
Gruß, André
OP
Inder
Geowizard
Möglicherweise dauert das Öffnen der 3.5er DB etwas länger als bei der 3.0, weil die 3.5 deutlich besser komprimiert ist. Meine DB ist beim Versionswechsel erheblich kleiner geworden (von 260MB auf 177MB). Die verlängerte Startzeit ist nicht schön, wäre aber in Anbetracht der kleineren Dateigröße zu verschmerzen. 10 Minuten bei der 533 sind aber jenseits der praktischen Nutzbarkeit.
Bitte keine Äpfel mit Birnen vergleichen!
Entweder gleiche Software auf unterschiedlicher Hardware oder unterschiedliche Software auf gleicher Hardware. Vergleiche unterschiedlicher Software auf unterschiedlicher Hardware sind für die Katz.
Die oben genannten, gravierenden Unterschiede von 520 zu 533 habe ich auf der identischen Hardware (HTC TouchPro 2) mit der gleichen Datenbank festgestellt.
Die Anzahl der Einträge ist auch relativ, da es sicher einen deutlichen Unterschied macht, ob man jeweils 5 Logs oder 100 Logs dabei hat.
Bitte keine Äpfel mit Birnen vergleichen!
Entweder gleiche Software auf unterschiedlicher Hardware oder unterschiedliche Software auf gleicher Hardware. Vergleiche unterschiedlicher Software auf unterschiedlicher Hardware sind für die Katz.
Die oben genannten, gravierenden Unterschiede von 520 zu 533 habe ich auf der identischen Hardware (HTC TouchPro 2) mit der gleichen Datenbank festgestellt.
Die Anzahl der Einträge ist auch relativ, da es sicher einen deutlichen Unterschied macht, ob man jeweils 5 Logs oder 100 Logs dabei hat.
Longri
Geoguru
Es gab noch eine Änderung von 520 auf 533, diese könnte ein längeres Laden auch verursachen.
@ Ging-Buh
Könntest du mal bitte den angehängten Patch Testen?
Ich glaube du kannst am besten einschätzen ob noch alle Funktionen deines Mysterys -Final-Waypoint-Patches funktionieren.
Ich habe das Laden deiner MysterySolutions in einen BackGround_Worker gepackt, kann aber nicht abschätzen ob diese Vorgehens weise irgendwelche Nebenwirkungen hat.
Wenn ein IO von dir kommt, werde ich den Patch so ein pflegen, oder wir müssen eine andere Lösung finden. Ich will und werde auf keinen Fall deinen Patch rückgängig machen, das finde ich nämlich eine Sinnvolle Funktion.
Gruß Longri
@ Ging-Buh
Könntest du mal bitte den angehängten Patch Testen?
Ich glaube du kannst am besten einschätzen ob noch alle Funktionen deines Mysterys -Final-Waypoint-Patches funktionieren.
Ich habe das Laden deiner MysterySolutions in einen BackGround_Worker gepackt, kann aber nicht abschätzen ob diese Vorgehens weise irgendwelche Nebenwirkungen hat.
Wenn ein IO von dir kommt, werde ich den Patch so ein pflegen, oder wir müssen eine andere Lösung finden. Ich will und werde auf keinen Fall deinen Patch rückgängig machen, das finde ich nämlich eine Sinnvolle Funktion.
Gruß Longri
cacheboxer
Geomaster
Wenn das so eine teure Funktion ist (wenn ich das richtig sehe, werden sämtliche Waypoints aller Multis, Mysterys und Whereigos im aktuellen Filter untersucht und die Finals auch noch in eine Liste eingetragen), würde ich lieber auf diese Funktion verzichten. Vielleicht kann man lieber das Prinzip der CorrectedCoordinates so aufbohren, dass es auch für Menschen ohne GSAK funktioniert?Longri schrieb:
Neben der Oberfläche ist die Performance bei großen Datenmengen das Hauptargument für Cachebox. Das darf man nicht aufgeben.
MfG
hanknstone
Geocacher
moin moin ...
also, bei mir verkürzt sich die Ladezeit der DB wie folgt:
HTC Touch 2, von ca. 2 Minuten auf 1 Min. 10 Sek. ..
MDA Compact V von 1 Minute 45 Sekunden auf rund 1 Minute.
rasant ! - das hat schon was
also, bei mir verkürzt sich die Ladezeit der DB wie folgt:
HTC Touch 2, von ca. 2 Minuten auf 1 Min. 10 Sek. ..
MDA Compact V von 1 Minute 45 Sekunden auf rund 1 Minute.
rasant ! - das hat schon was
Longri
Geoguru
hanknstone schrieb:moin moin ...
also, bei mir verkürzt sich die Ladezeit der DB wie folgt:
HTC Touch 2, von ca. 2 Minuten auf 1 Min. 10 Sek. ..
MDA Compact V von 1 Minute 45 Sekunden auf rund 1 Minute.
rasant ! - das hat schon was
Ich gehe mal davon aus, das die verkürzung der Zeit mit dem Patch gemeint ist?
Jetzt ist nur noch die Frage ob alle Funktionen noch gehen?
Insbesondere die Frage ob es zu Problemen kommt wenn die MysterySolutions, im Hintergrund, noch geladen wird und gleichzeitig, von einer anderen Stelle aus, auf die Liste zugegriffen wird.
hanknstone
Geocacher
ja, war so gemeint - nach dem Patch wurds schneller :->Longri schrieb:
sorry, das mag ich nicht beurteilen ... da ich den Solver bislang nicht wirklich in Funktion hatte....Longri schrieb:
Der Gieger
Geocacher
hanknstone schrieb:
Gab es da nicht schon einen ganz tollen externen Solver? Der geht aber leider nur mit der Datenbank von GSAK. Da wäre es vielleicht gut, diesen Solver auf Verwendbarkeit zu testen und bei Gefallen eine Exportfunktion in dieses DB-Format von GSAK einzubauen. Ist, glaube ich, SQLite.
Longri
Geoguru
hanknstone schrieb:
Das hat nichts mit dem Solver zu tun.
Ging-Buh hat auch einen Patch für die Mysterys und dessen Final geschrieben. Und eben dieser läuft beim Start auch an. Ich werde einmal mein HD2 löschen und es auf diesem testen. Im Emulator kann ich nur kleine DB´s Testen.
Die Tatsache, dass alle Mystery-Solutions beim Laden der Cacheliste in einer eigenen Liste gespeichert werden hat nichts mit meinem Patch zu tun. Das war schon vorher so. Auch vorher wurden zusätzlich zu den Caches auch die Final-Waypoints in der Karte angezeigt. Mein Patch wirkt sich nur auf die Darstellung in der Karte aus.Longri schrieb:
Beim Hinzufügen der Funktion "Add Final" zum Solver habe ich allerdings die Funktion LoadMysterySolutions aus der Funktion "LoadCaches" herausgetrennt, um diese nach dem Hinzfügen eines Finals gesondert aurufen zu können. Dabei habe ich auch die Berechnung umgebaut. Ich werde mal testen, ob die alte Art schneller war.
Ich könnte mir durchaus vorstellen, dass die Berechnung der Mystery-Solutions in einem eigenen Thread Probleme machen könnte. Beim Anzeigen der Map wird dauernd auf diese Liste zugegriffen.
Hab gerade die alte und die aktuelle Variante vom Laden der Mystery-Solutions gegeneinander antreten lassen.
Hab in meiner DB nur gut 800 Caches auf meinem HTC Touch Pro.
Die Funktion LoadCaches ohne das Laden der MysterySolutions Liste dauert ca. 33 sec.
Die aktuelle Variante braucht für das Laden der MysterySolutions ca. 10-11 sec, die alte (von mir entfernte) schaffte das in 1 sec. Ich denke, mit dieser Variante erübrigt sich die Auslagerung in einen eigenen Thread.
Meine aktuelle Variante durchsucht alle Caches nach Final-Waypoints. Die alte Variante lädt per SQL direkt alle Finals und verknüpft diese dann mit den Caches. Da doch die wenigsten Caches Mysterys mit Finals sind ist die alte Variante viel schneller.
Ich werde mir das ganze noch mal durch den Kopf gehen lassen, wie ich die alte Variante mit dem Hinzufügen der Final-Waypoints aus dem Solver vereinen kann und bei Erfolg einen Patch erstellen.
Hab in meiner DB nur gut 800 Caches auf meinem HTC Touch Pro.
Die Funktion LoadCaches ohne das Laden der MysterySolutions Liste dauert ca. 33 sec.
Die aktuelle Variante braucht für das Laden der MysterySolutions ca. 10-11 sec, die alte (von mir entfernte) schaffte das in 1 sec. Ich denke, mit dieser Variante erübrigt sich die Auslagerung in einen eigenen Thread.
Meine aktuelle Variante durchsucht alle Caches nach Final-Waypoints. Die alte Variante lädt per SQL direkt alle Finals und verknüpft diese dann mit den Caches. Da doch die wenigsten Caches Mysterys mit Finals sind ist die alte Variante viel schneller.
Ich werde mir das ganze noch mal durch den Kopf gehen lassen, wie ich die alte Variante mit dem Hinzufügen der Final-Waypoints aus dem Solver vereinen kann und bei Erfolg einen Patch erstellen.
Longri
Geoguru
Ging-Buh schrieb:
Sorry das war dann wohl der falsche Weg, ich hätte dich lieber erst einmal Persönlich ansprechen sollen.
Wenn die Mystery-Solutions einmal geladen ist sollte es eigentlich auch keine Probleme geben.
Und die ersten Tests mit einem Filter auf Whereigo,Multi,Mystery ergaben auch bei der Karten-Darstellung keine Probleme.
Ich habe den Patch jetzt noch ein wenig erweitert.
Das Laden der Caches und das Anwenden eines Filters werden jetzt auch mit einem BackGroundWorker erledigt.
Ich werde diese Variante am Wochenende ausgiebig Testen. (Ich hoffe es geht nichts schief, sonst bin ich aufs IPhone meiner Frau angewiesen)
Im Anhang ist der Patch zum selber Kompilieren und eine EXE zum Austausch auf Basis der Rev. 551
Am Montag möchte ich dann kurze Ladezeiten sehen und keine Fehlermeldungen.
Und denkt bitte daran ein BackUp zu machen, die Versuche beziehen sich immerhin auf das Laden der DB.
Werde ich gerne testen, aber (und entschuldige bitte meine naive Frage) denkst du es macht Sinn, beim Start von CacheBox das Laden der DB in einen Thread auszulagern? Was hilft es mir wenn CB schnell startet, aber die DB noch nicht komplett geladen ist?Longri schrieb:
Ich denke, ich hab schon eine Lösung, wie ich den Aufruf der Funktion LoadMysterySolutions nach dem Hinzufügen eines Finals aus dem Sover vermeiden kann. Bin aber noch am Testen...
Hab's gestern noch kurz getestet. Ladezeiten sind sehr schnell. Hatte aber sofort Abstürze, wenn ich direkt nach dem Laden z.B. in die Map gewechselt bin.Longri schrieb:
Problem dabei könnte einfach sein, dass während einem foreach Zugriff auf Cache.Query durch den Thread Einträge hinzugefügt werden -> Absturz.
Hab mir dann die Ladezeiten nochmal genauer angesehen und festgestellt, dass mit Abstand die meiste Zeit für die Sortierung verbraucht wird. Das Laden der Caches und die Erstellung der MysterySolutions-Liste geht da viel schneller.
Ich werd mir das ganze heute Abend nochmal genauer ansehen (hab auch schon eine Idee, wie es schneller werden könnte) und dann auch den Patch für die MysterySolutinos erstellen.
Grundsätzlich aber denke ich, dass die User, die 5000 oder mehr Caches dabei haben, diese Datenbank vielleicht mit WinCB in mehrere kleine aufteilen könnten. Das würde die Ladezeiten mit Abstand am besten reduzieren.
GeoSilverio
Geowizard
Ja, das verschieben des langdauernden Prozesses in den Hintergrund ist zwar "schick", da man das Gefühl hat CB startet fix. Allerdings kann man es dann nicht verwenden, da der Prozess im Hintergrund ja genau so lange läuft und vorher kein vernünftiges Arbeiten möglich ist, selbst wenn es nicht abstürzen sollte...
Longri
Geoguru
Hi,
ich komme gerade von einem langen Tag im Wald zurück und muss sagen, dass es wohl ein Schuss in den Offen war.
War halt nur so eine Idee, die langwidrigen Sachen auszulagern.
Da werden wir wohl einen anderen Weg finden müssen,
denn da sind wir uns wohl einig, dieses Problem sollte bis zum nächsten offiziellen Release beseitigt oder wenigstens gemildert werden.
Gruss Longri
ich komme gerade von einem langen Tag im Wald zurück und muss sagen, dass es wohl ein Schuss in den Offen war.
War halt nur so eine Idee, die langwidrigen Sachen auszulagern.
Da werden wir wohl einen anderen Weg finden müssen,
denn da sind wir uns wohl einig, dieses Problem sollte bis zum nächsten offiziellen Release beseitigt oder wenigstens gemildert werden.
Gruss Longri