Notizen/Solver in Liste?

[Engywuck]

Liebe Gemeinde,
ich fände es oft praktisch, wenn ich schon in der Liste sehen könnte, wenn zu einem Cache Solver-Einträge oder (weniger spannend) Notizen vorhanden sind. Mir würde vorschweben, dass man die in der Liste durch zusätzliche Spalten und kleine Symbole anzeigt, ob welche vorhanden sind. Wie man die statusanzeigen von Mailprogrammen kennt...
Was haltet ihr davon?

Gruß,
E.

 

[maierkurt]

Das wäre sicher schön,.... wenn ich einen 1024x768 PDA hätte.
Ich weiß jetzt aber nicht, ob ich diese Funktionalität mal gebraucht hätte.


Gruß, maierkurt

 

[Engywuck]

Die Listen sind natürlich (wie üblich) konfigurierbar. Praktisch fände ich das für den Fall, dass ich (z.B. für einen Urlaub) eine größere Menge Caches vorbereite, und dann schwer den Überblick verliere, bei welchen ich den Solver noch vorbereiten muss und bei welchen schon Daten da sind. Oder auch, wenn ich mein Home-Profil pflege.
Das ist eigentlich mein Haupt-Zweck.

Gruß,
E.

 

[t31]

Finde die Idee gut.

Das wäre sicher schön,.... wenn ich einen 1024x768 PDA hätte.
Ich weiß jetzt aber nicht, ob ich diese Funktionalität mal gebraucht hätte.

Daran soll es nicht scheitert, man kann jetzt schon die Spalten auswählen die angezeigt werden sollen. In der Regel wird man eine solche Funktionalität eh nur am PC nutzen und da sind bekanntermaßen solche Auflösungen kein Hexenwerk. Am PDA blendest du die Spalte aus, fertigt.

 

[maierkurt]

und dann schwer den Überblick verliere, bei welchen ich den Solver noch vorbereiten muss und bei welchen schon Daten da sind.

in Verbindung mit

..In der Regel wird man eine solche Funktionalität eh nur am PC nutzen..

Ja, ok, ich habe mir die Sache nochmal durch den Kopf gehen lassen. Es gibt bei mir natürlich auch gewisse Multis, da kann man schon gute Vorarbeit leisten. Dies mache ich aber normalerweise nur, wenn der Cache gerade ansteht, oder eben wenn ich Zeit habe.

Kurzum: Ich würde diese Funktion durchaus begrüßen.

Es muss dann aber ersichtlich sein, ob entweder eine Notiz vorhanden ist oder der Solver gefüllt ist.


Gruß, maierkurt

 

[Silas]

Ich könnte es auch gebrauchen.

 

[salzkammergut]

Finde es auch nicht schlecht nur bläht es die index.xml weiter auf (und verlangsamt das Laden der index.xml am PDA - ist das merkbar?).

Gruß
skg

 

[Engywuck]

ist das merkbar?

Meine Vermutung: Nein. Die beiden Informationen "Notizen ja/nein, Solver ja/nein" packt man am besten in einen Eintrag (note_solv="XX"), das spart Platz und erhöht den Speicherbedarf relativ gesehen nur minimal.

Gruß,
E.

 

[MiK]

Natürlich isterstmal so ein einzelner Wert kaum merkbar. Aber je mehr Caches man im Profil hat um so deutlicher merkt man jeden unnötigen Eintrag in der index.xml. Wir sollten uns überlegen, das Format komplett zu überarbeiten. Für was dient hier eigentlich attributesYes und attributesNo? Man könnte auch viele bool-Parameter in einem Status-Bitfeld zusammenfassen.

Dazu müsste man natürlich eine Versionsinfo hinterlegen und auch die alte Einlesemethode beibehalten. Beim Speichern wird dann im neuen Format geschrieben und beim nächsten Start hoffentlich schneller geladen.

 

[greiol]

Dazu müsste man natürlich eine Versionsinfo hinterlegen und auch die alte Einlesemethode beibehalten. Beim Speichern wird dann im neuen Format geschrieben und beim nächsten Start hoffentlich schneller geladen.

ich hätte da nichts gegen, denn das profil mit meinen funden wird entgegen aller empfehlungen für profilgrößen im laufe der zeit nicht kleiner . und gegen einen generelle performanceverbesserung beim starten habe ich auch nichts.

zusatzfrage: könnte man recht weit vorne in der jeweiligen zeile evtl. ein kleines flag unterbringen ob es ein addi ist (zumindest os lange die zeile als text und stückweise interpretiert wird)? bei denen könnte man sich einiges an zu schreibenden und zu lesen daten im gegensatz zu einem "richtigen" wegpunkt sparen. bei einem tradi-only profil würde das natürlich overhead erzeugen, bei einem gemischten profil könnte ich mir eine ersparnis vorstellen.

 

[Engywuck]

Zur Geschwindigkeit ein paar Messungen auf meinem PDA auf meinem nicht zu kleinen Home-Profil. Ich habe zunächst viel Funktionalität beim Laden ausgeschaltet und dann nach und nach zugeschaltet, um zu sehen, wo die Zeit bleibt. Das sind meine Ergebnisse (grob):
- Nur Lesen der index.xml, ohne Verarbeitung: 10 sek
- Mit Erzeugen (leerer) CacheHolder-Objekte pro gefundenem Cache: 17 sek
- Mit Interpretation der Cache-Daten: 40 sek
- Mit zweifacher Interpretation der Cache-Daten: 50 sek

Es scheint so zu sein, dass die Zeit, die das Einlesen braucht, schön auf alle Komponenten des Einlesens verteilt ist. Es würde also helfen:
- Kürzere index.xml
- Weniger zu interpretierende Daten

Im CacheHolder-Objekt gibt es 12 boolsche Eigenschaften, die alle einzeln in der Datei abgelegt werden. Diese könnte man gut als Bitmuster in einem Long unterbringen und auslesen (wie es für die Attributes ja schon gemacht wird). Das sollte Bytes sparen, die Interpretation des Strings verbessern und (da nur Bitmuster gelesen werden müssen) vermutlich auch die Interpretation der Daten beschleunigen.
Ich glaube, ich teste das mal aus... Wenn nicht jemand eine bessere Idee postet.

Gruß,
E.

 

[Engywuck]

Erstes Ergebnis: Mit dem Bitfeld für die Boolschen Werte schrumpt die index.xml schon mal von 486 kB auf 301 kB...

Gruß,
E.

 

[Engywuck]

So, hier sind die Resultate:
Bei meinem Homeprofil:
Größe: 486 kB -> 305 kB
Ladezeit: etwas mehr als 40 sek -> etwas weniger als 40 sek

Größeres Profil aus dem Urlaub:
Größe: 1,51 MB -> 764 kB
Ladezeit: 90 sek -> 65 sek

Das sieht ja gar nicht sooo schlecht aus. Der Nachteil ist natürlich, dass man die boolschen Eigenschaften jetzt nicht mehr "plain" aus der XML-Datei lesen kann. Ich hab das ganze abwärtskompatibel gebaut und auch mit einer Versionsnummer versehen - falls sich nochmal was ändert ;-)

Da die Änderung die Struktur der XML-Dateien ändert, hänge ich die Codeänderungen erstmal als Patch an. Nur wer wirklich weiß, was er tut, kann sie damit ausprobieren...

Was sagen die Profis? Wollen wir das übernehmen?

Gruß,
E.

 

[salzkammergut]

Hallo Engywuck,

super, dass Du das mal genauer untersuchst. Das mit den booleschen Feldern hab ich auch schon überlegt aber dann aus Gründen der Lesbarkeit der index.xml nicht gemacht. Nach nochmaligem Nachdenken und unter Berücksichtigung Deiner Ergebnisse sehe ich das aber inzwischen nicht so problematisch. Die booleschen Variablen könnten auch im Cacheholder als ein int gespeichert werden (das müßte beim Einlesen nochmals Zeit sparen) und über Getter/Setter wieder in true/false umgewandelt werden. Das würde man beim Scrollen wohl kaum merken.

Ein großes Problem scheint auch zu sein, dass EWE bei der Objekterzeugung viel Zeit verbraucht. Interessant wäre da noch ein Test, der die index.xml parst, aber dann den letzen Schritt (=die Erzeugung diverser Strings) wegläßt. Da fällt mir noch ein: Es kann auch noch Objekterzeugungszeit gespart werden indem z.B. die Cachegröße und Schwierigkeit intern nicht in Strings sondern in ints gespeichert werden.

Grüße
skg

 

[Engywuck]

Die booleschen Variablen könnten auch im Cacheholder als ein int gespeichert werden (das müßte beim Einlesen nochmals Zeit sparen) und über Getter/Setter wieder in true/false umgewandelt werden. Das würde man beim Scrollen wohl kaum merken.

Zusätzlich: Es spart etwas Speicher im CacheHolder-Objekt. Eine boolsche Variable braucht (vermutlich?) auch 4 Byte (obwohl ein Bit reichen würde) plus etwas Verwaltungsoverhead pro Variable. Wenn man das zusammenfasst in eine kann man schon was sparen. Dafür hat man dann natürlich immer den Rechenaufwand, daraus per Getter/Setter die Boolschen Werte zu extrahieren, und zwar jedes Mal, wenn man sie braucht.

Ein großes Problem scheint auch zu sein, dass EWE bei der Objekterzeugung viel Zeit verbraucht. Interessant wäre da noch ein Test, der die index.xml parst, aber dann den letzen Schritt (=die Erzeugung diverser Strings) wegläßt.

Den Teil hab ich nicht verstanden...

Da fällt mir noch ein: Es kann auch noch Objekterzeugungszeit gespart werden indem z.B. die Cachegröße und Schwierigkeit intern nicht in Strings sondern in ints gespeichert werden.

Das wäre noch eine Idee. Man könnte so "Kleinscheiß-Infos" als Bytes ablegen - dann könnten 8 davon wieder als ein long gespeichert werden. Hab jetzt aber nicht nachgeschaut, wie viele man so abbilden könnte.
Wenn wir so weitermachen, speichern wir bald im Binärformat ;-)

Gruß,
E.

 

[MiK]

Was sagen die Profis? Wollen wir das übernehmen?

Ohne es mir jetzt schon genauer angesehen zu haben: Generell bin ich dafür. Aber warte noch ab, bis wir die Diskussion hier "abgeschlossen" haben und vielleicht noch weitere Änderungen getestet haben. Sonst schießt die Versionsnummer sehr schnell in die Höhe und wir brauchen viel Code um alle Versionen zu handhaben.

 

[Silas]

Die booleschen Variablen könnten auch im Cacheholder als ein int gespeichert werden (das müßte beim Einlesen nochmals Zeit sparen) und über Getter/Setter wieder in true/false umgewandelt werden. Das würde man beim Scrollen wohl kaum merken.

Zusätzlich: Es spart etwas Speicher im CacheHolder-Objekt. Eine boolsche Variable braucht (vermutlich?) auch 4 Byte (obwohl ein Bit reichen würde) plus etwas Verwaltungsoverhead pro Variable. Wenn man das zusammenfasst in eine kann man schon was sparen. Dafür hat man dann natürlich immer den Rechenaufwand, daraus per Getter/Setter die Boolschen Werte zu extrahieren, und zwar jedes Mal, wenn man sie braucht.

Oder man speichert sich nach dem ersten Getter-Aufruf, der den Boolean-Wert berechnet, diesen doch, dann sind alle weiteren Zugriffe schnell. Lediglich der Speicher-Bedarf steigt dadurch wieder etwas. Oder ruft man sowieso die Getter jedes CacheHolders auf? Dann bringts natürlich nichts. Ich gebe zu, dass ich noch nicht so verinnerlicht habe, wo im Programm was instanziert und genutzt wird (wird auch noch bisschen dauern )

Ein großes Problem scheint auch zu sein, dass EWE bei der Objekterzeugung viel Zeit verbraucht. Interessant wäre da noch ein Test, der die index.xml parst, aber dann den letzen Schritt (=die Erzeugung diverser Strings) wegläßt.

Den Teil hab ich nicht verstanden...

Das Speichern der Strings in den CacheHoldern?

Was sagen die Profis? Wollen wir das übernehmen?

Ohne es mir jetzt schon genauer angesehen zu haben: Generell bin ich dafür. Aber warte noch ab, bis wir die Diskussion hier "abgeschlossen" haben und vielleicht noch weitere Änderungen getestet haben. Sonst schießt die Versionsnummer sehr schnell in die Höhe und wir brauchen viel Code um alle Versionen zu handhaben.

Sehe ich auch so.

Eine Kleinigkeit noch zum Konvertieren der XMLs ins neue Format: Ich hielte es für ein besseres Design, wenn CW beim Start erkennt, dass die Dateien einem alten Format entsprechen und sie dann direkt alle konvertiert. Idealerweise natürlich mit Fortschrittsanzeige wie beim Speichern. Hierfür sollte es eine eigene Klasse geben, die beim Start immer aufgerufen wird und die Formate prüft und wenn erforderlich aktualisiert. Dann müsste diese Format-Unterscheidung nicht in der "richtigen" Applikation erfolgen, sondern die könnte sich immer aufs aktuelle Schema verlassen.
Ist in meinen Augen aber eher ein Architektur-Nice2Have als wirklich erforderlich, da das Parsen so ja auch nur an einer Stelle stattfindet.

 

[Engywuck]

Ok, weitere Zusammenfassungen: Typ, Difficulty, Terrain und Anzahl-nicht-gefunden könnten jeweils als Byte abgelegt werden und hätten dann in der Datei auch gut in einem Long abgelegt werden. Die beiden "num recommendation" Felder sind jeweils ein int, die auch beide zusammen in ein long passen. Macht insgesamt 6 Einträge, die man auf 2 zusammenschnurren könnte. Wobei ich jetzt nicht im Kopf habe, wie aufwendig es ist, mehr als ein Bit (also z.B. ein Byte) aus einem Long zu extrahieren.

Gruß,
E.

 

[Robin888]

Also ohne den technischen Kram jetzt komplett gelesen zu haben:

Wenn ich einen Multi vorbereitet oder einen Mystery gelöst habe, dann setze ich eine entsprechende Notiz im Status-Feld. (Momentan noch "Merker 2".)

Die gesamte Hierarchie bei mir:

Merker 1: Interessanter Cache
Merker 2: Vorbereitet, kann gesucht werden
Merker 3: Suche abgebrochen
Merker 4: Nicht gefunden
Gefunden $datum $uhrzeit: Cache gefunden am $datum um $uhrzeit

Robin(888)

 

[greiol]

Eine Kleinigkeit noch zum Konvertieren der XMLs ins neue Format: Ich hielte es für ein besseres Design, wenn CW beim Start erkennt, dass die Dateien einem alten Format entsprechen und sie dann direkt alle konvertiert. Idealerweise natürlich mit Fortschrittsanzeige wie beim Speichern. Hierfür sollte es eine eigene Klasse geben, die beim Start immer aufgerufen wird und die Formate prüft und wenn erforderlich aktualisiert.

diese klasse müsste dann aber vermutlich durch alle dateien gehen, denn sonst gibt es lustig effekte beim verschieben/kopieren eines caches aus einem konvertierten in ein noch nicht konvertiertes profil. das dürfte aber den kompletten startvorteil den wir oben heraus gearbeitet haben locker wieder zu nichte machen. aus performance sicht wäre da ein externes tool das einmal in einem rutsch alles konvertiert vermutlich unschädlicher, aber es hat halt den usability nachteil.