Speichern bei Beenden

[Engywuck]

Diese Heuristiken zum Thema "Wann muss gespeichert werden?" stören mich schon länger... Wie wäre es, wenn man die Informationen der Index.xml, die zum Speichern nötigen, per Getter/Setter verwendet und in der jeweiligen Setter-methode das Speichern-Flag setzt. Dann ist es egal, aus welchem Kontext die Daten in index.xml geändert werden - wenn es relevante Daten sind, weiss die Liste selber, dass sie sich speichern muss.
Ich weiß nur nicht, ob der Zugriff über Funktionen langsamer ist als der Zugriff über Public-Felder, insbesondere auf dem PDA.

Gruß,
E.

 

[MiK]

Dazu müsste aber die Liste als einzelnes Objekt existieren und immer über diese auf die Cachedaten zugegriffen werden. Im Moment können aber die Daten eines Caches ganz unabhängig von der Liste geladen und geändert werden.

 

[MiK]

Bilder hab ich noch nie angehängt... Notizen allerdings sehr wohl. Das nutze ich häufig.

Ich nutze auch für Notizen mittlerweile eher den Solver. Das funktioniert auf dem PDA für mich einfacher und schneller.

 

[Engywuck]

Dazu müsste aber die Liste als einzelnes Objekt existieren und immer über diese auf die Cachedaten zugegriffen werden. Im Moment können aber die Daten eines Caches ganz unabhängig von der Liste geladen und geändert werden.

Ach ja richtig. Die Liste ist ja nur eine Liste von Cache-Objekten. Ok, kleine Änderung: Die Getter/Setter-Methoden werden in den Cache-Objekten eingeführt. Dort kann man (an der gleichen Stelle) auch gleich zwei Flags verwalten: Einmal "Führt zum Speichern der Liste" und "Führt zum Speichern des Caches".

Gruß,
E.

 

[MiK]

Und wie und wann soll das Profil (das ist für das Laden und Speichern der index.xml verantwortlich) dann mitbekommen, dass es beim Beenden die index.xml speichern muss?

 

[Engywuck]

Weil das Listen-Flag nicht im Cacheobjekt liegt, sondern da, wo es jetzt auch schon liegt...

Gruß,
E.

 

[pfeffer]

Mir erscheint Engywucks Vorschlag auf jeden Fall sauberer und sinnvoll. Normalerweise ist allerdings ein Funktionsaufruf deutlich langsamer als ein Zugriff auf ein Public-Feld.
Deswegen sollte man vielleicht den Zugriff über getter und setter auf den "normalen" Zugriff beschränken, während beim Im- und Export evtl. weiterhin public Felder genutzt werden sollten, weil dabei der Zugriff wesentlich entscheidender für die Performance ist.

Gruß,
Pfeffer.

 

[Engywuck]

Normalerweise ist allerdings ein Funktionsaufruf deutlich langsamer als ein Zugriff auf ein Public-Feld.
Deswegen sollte man vielleicht den Zugriff über getter und setter auf den "normalen" Zugriff beschränken, während beim Im- und Export evtl. weiterhin public Felder genutzt werden sollten

Ich vermute, dass Dein Einwand nur theoretisch gerechtfertigt ist, und zwar aus folgender Überlegung:
Ein TomTom-Export bei meinem Home-Profil dauert vielleicht so 15 sek. Wenn ich dagegen das Zentrum neu setzen, so braucht die Neuberechnung für alle Caches nur wenige Sekunden. Bei der Neuberechung werden jedoch deutlich mehr Rechnungen durchgeführt (Großkreise...), außerdem eine externe Library genutzt, die sicher noch mal etliche Funktionen aufruft. Und das alles pro Cache. Und dennoch dauert dies nur wenige Sekunden.
Folgerung: Der zeitkritische Faktor ist beim Export ist nicht der Funktionszugriff. Vielleicht dauert bei Verwendung von Funktionen der Export nur 19 statt 20 Sekunden - aber auch da wäre ich skeptisch.

Gruß,
E.

 

[pfeffer]

ok, mach es!
Und falls sich die export- oder import-Zeit verdoppeln sollte, dann muss es dabei eben rückgängig gemacht werden. Aber wahrscheinlich hast Du recht und alles wird sauberer durch Deinen Vorschlag.

Ich finde auch die von Dir erfolgt Umstellung auf Int bei den Cachetypen war wirklich nötig. Weiter so ;-)

Gruß,
Pfeffer.

 

[Engywuck]

ok, mach es!

Ich werde mich mal dransetzen, wenn ich wieder zu Hause bin und das Wetter nicht mehr cache-tauglich ist ;-)

Und falls sich die export- oder import-Zeit verdoppeln sollte, dann muss es dabei eben rückgängig gemacht werden.

Jo, dann geht ja immer noch Deine Lösung.

Aber wahrscheinlich hast Du recht und alles wird sauberer durch Deinen Vorschlag.

Ich werden dann zumindest mal vor und nach der Umstellung die Zeit messen.

Ich finde auch die von Dir erfolgt Umstellung auf Int bei den Cachetypen war wirklich nötig.

Wenigstens hier hatte ich gehofft, dass sich vielleicht ein kleiner Geschwindigkeitseffekt zeigt, z.B. bei der Darstellung im Radar. Hab aber leider subjektiv keine Effekte feststellen können :-/

Gruß,
E.

 

[Silas]

Benutzt jemand diese Funktion? - Ich wäre sonst dafür sie zur Komplexitätsreduktion zu streichen.

Gruß,
Pfeffer.

Bin ich auch für. Habe sie zwar schon einmal genutzt, aber mehr ums auszuprobieren.

Die Notizen benutze ich, um zu Hause Multis vorzubereiten und kopiere dann vor Ort den Inhalt nur noch in den Solver. Außerdem vermerke ich mir da Koordinaten von Multi-Stages und Mysteries, falls ich noch mal hinwill. Eigentlich wären dafür ja andere Waypoints gedacht, aber damit habe ich mich noch nie befasst, weils mir zu umständlich erschien.

 

[Kappler]

Die Notizen benutze ich, um zu Hause Multis vorzubereiten und kopiere dann vor Ort den Inhalt nur noch in den Solver.

Du kannst auch direkt im Solver vorbereiten: Der Solverinhalt wird beim Cache mitgespeichert.

 

[Silas]

Oh cool, war das immer schon so?

 

[MiK]

Oh cool, war das immer schon so?

Zumindest schon sehr lange. Davor gab es im Solver eine Möglichkeit die Solverdaten zu speichern und wieder zu laden.

 

[Engywuck]

Zu meinem Posting hier: Ich habe die Änderungen jetzt mal eingebaut. Glücklicherweise habe ich keine Geschwindigkeitseinbußen feststellen können. Aber er sollte jetzt etwas weniger oft speichern, nämlich nur noch dann, wenn es benötigt wird.
Bei meinen Tests ist alles gut gegangen, trotzdem kann ich nicht die Hand dafür ins Feuer legen, dass alles so klappt wie vorher. Einfach mal ausprobieren
Weitere Optimierungsarbeiten werden dann noch folgen.

Gruß,
E.

P.S.: Falls sich irgendwas seltsames tut, bitte melden!