Änderung im Dateiformat

[MiK]

Wenn ich greiol richtig verstanden habe, gibt es dafür extra Konstanten, die bei Addis verwendet werden und die (nur bei Addis) dann keine Exceptions werfen sollten.

 

[Engywuck]

Ich versuche hier gerade, ein V1-Profil einzulesen, und mir fliegen die Exceptions um die Ohren wie Bruce Willis die Pistolenkugeln in Die Hard.
Ich verstehe auch nicht ganz, wieso man Variablen explizit auf Werte setzt, die dann an anderer Stelle Exceptions auslösen....
Mir scheint das noch alles andere als rund zu sein.

Gruß,
E.

 

[Engywuck]

Es sieht so aus, als ob die Konstante CW_DT_ADDITIONAL nur beim Spidern benutzt wird. Beim Einlesen aus einem V1-Format wird dagegen eine Angabe wie terrain = "", wie sie für Addis typisch ist, als ungültig erachtet und mit dem Wert CW_DT_ERROR versehen und so abgespeichert. Womit jetzt in Version 3 alle Addis vermutlich erstmal eine ungültige Angabe zu terrain und size haben. Nicht so toll...

Gruß,
E.

P.S.: Das aktualisieren von OC-Virtuals führt immer zu incomplete-Caches.

 

[Engywuck]

Ach ja: Custom Waypoints bekommen auch immer den Stempel "ungültig" für Terrain und Size.

 

[greiol]

Wie sieht das eigentlich aus mit Size, Terrain und Difficulty für Addis? Werfen die jetzt alle eine IllegalArgumentException ?

ja, wenn daten auftauchen die so nicht erwartet werden wird eine Exception ausgelöst.

Ich versuche hier gerade, ein V1-Profil einzulesen, und mir fliegen die Exceptions um die Ohren wie Bruce Willis die Pistolenkugeln in Die Hard.

also wenn dann bitte "last man standing". du hast nicht zufällig debug output angeschaltet? es gab eine menge stellen, die frühe mit einem catch (Exception e) {} einfach alles weggebügelt haben und nun bekommt man mit dem debugschalter doch tatsächlich eine meldung.

Ich verstehe auch nicht ganz, wieso man Variablen explizit auf Werte setzt, die dann an anderer Stelle Exceptions auslösen....
Mir scheint das noch alles andere als rund zu sein.

es behauptet niemand dass alles rund ist und ich freue mich über rückmeldungen von testern. wenn die nun noch schreiben würden wie sie die fehler ausgelöst haben statt sie nur aufzulisten ...

Es sieht so aus, als ob die Konstante CW_DT_ADDITIONAL nur beim Spidern benutzt wird. Beim Einlesen aus einem V1-Format wird dagegen eine Angabe wie terrain = "", wie sie für Addis typisch ist, als ungültig erachtet und mit dem Wert CW_DT_ERROR versehen und so abgespeichert. Womit jetzt in Version 3 alle Addis vermutlich erstmal eine ungültige Angabe zu terrain und size haben. Nicht so toll...

mit der meldung kann ich doch etwas anfangen. da werde ich mal nachsehen

P.S.: Das aktualisieren von OC-Virtuals führt immer zu incomplete-Caches.

dann sollte ich mir vermutlich auch den oc xml impoter nochmal ansehen. danke für den hinweis.

Ach ja: Custom Waypoints bekommen auch immer den Stempel "ungültig" für Terrain und Size.

die habe ich doch dann wohl glatt übersehen

 

[Engywuck]

du hast nicht zufällig debug output angeschaltet? es gab eine menge stellen, die frühe mit einem catch (Exception e) {} einfach alles weggebügelt haben und nun bekommt man mit dem debugschalter doch tatsächlich eine meldung.

Klar, hab ich. Deshalb ist es mir ja auch aufgefallen: Vor Deinen Änderungen war an der Front alles ruhig, jetzt kommen die ganzen Exceptions....

Ich verstehe auch nicht ganz, wieso man Variablen explizit auf Werte setzt, die dann an anderer Stelle Exceptions auslösen....

es behauptet niemand dass alles rund ist und ich freue mich über rückmeldungen von testern. wenn die nun noch schreiben würden wie sie die fehler ausgelöst haben statt sie nur aufzulisten ...

Dies bezog sich auf folgendes: Du setzt die Size- und Terrain-Werte auf eine Ungültig-Konstante, wenn ein Wert geparst wird, mit dem Du nichts anfangen kannst. Das ist ja in Ordnung. Die Funktionen, die dann aus den internen Daten wieder extern darstellbare machen (String, Bilder...), werfen aber wiederum eine Exception, wenn sie auf den von Dir selbst gesetzten Error-Wert stoßen, und das ist eigentlich nicht richtig. Exceptions sollen dann verwendet werden, um unerwartete Werte abzufangen - aber ein Wert, den man selber gesetzt hat, kann man guten Gewissens nicht als unerwartet bezeichnen. Vielleicht ungewollt, aber das ist eine ganz andere Baustelle.

Heute Abend kann ich dann mal wieder gucken, ob's jetzt besser aussieht

Gruß,
E.

 

[greiol]

du hast nicht zufällig debug output angeschaltet? es gab eine menge stellen, die frühe mit einem catch (Exception e) {} einfach alles weggebügelt haben und nun bekommt man mit dem debugschalter doch tatsächlich eine meldung.

Klar, hab ich. Deshalb ist es mir ja auch aufgefallen: Vor Deinen Änderungen war an der Front alles ruhig, jetzt kommen die ganzen Exceptions....

- wer debug output anschaltet darf sich nicht wundern wenn er auch welchen bekommt
- es werden abgefangene exceptions protokolliert. früher wurden die einfach weggeworfen. das ist in weiten teilen des codes bedauerlicherweise immer noch so
- sollten exceptions ausgegeben werden ohne dass ein if (Global.getPref().debug) davor steht würde ich das allerdings auch als bug ansehen

Ich verstehe auch nicht ganz, wieso man Variablen explizit auf Werte setzt, die dann an anderer Stelle Exceptions auslösen....

es behauptet niemand dass alles rund ist und ich freue mich über rückmeldungen von testern. wenn die nun noch schreiben würden wie sie die fehler ausgelöst haben statt sie nur aufzulisten ...

Dies bezog sich auf folgendes: Du setzt die Size- und Terrain-Werte auf eine Ungültig-Konstante, wenn ein Wert geparst wird, mit dem Du nichts anfangen kannst. Das ist ja in Ordnung. Die Funktionen, die dann aus den internen Daten wieder extern darstellbare machen (String, Bilder...), werfen aber wiederum eine Exception, wenn sie auf den von Dir selbst gesetzten Error-Wert stoßen, und das ist eigentlich nicht richtig. Exceptions sollen dann verwendet werden, um unerwartete Werte abzufangen - aber ein Wert, den man selber gesetzt hat, kann man guten Gewissens nicht als unerwartet bezeichnen. Vielleicht ungewollt, aber das ist eine ganz andere Baustelle.

ich kann die verwunderung verstehen, werde aber versuchen zu erklären was da warum geschieht.
- eingaben sind grundsätzlich nicht vertrauenswürdig, egal woher sie stammen (das betrifft natürlich erst mal die importer)
- der cacheholder selber ist streng genommen auch ein importer
- deshlab gibt es auch eine validierung beim einlesen der v1 und v2 formate
- würde ich die daten im cacheholder aber auch bei jedem lesen von v3 vollständig validieren, wäre der gesamte performance vorteil der format umstellung dahin
- dadurch enthält das profil nicht vertrauenswürdige daten (wer weiss schon wie der anwender sein index file erzeugt hat ...)
- also gibt es als "zweite verteidigungslinie" die validierung vor der anzeige, insbesondere im details panel, hier wird dann geprüft ob ich mit den daten die im cache stehen etwas anfangen kann und ggf. eingegriffen, da der overhead bei einer einzelnen anzeige eben deutlich geringer ist als beim einlesen des profils zuzuschlagen
- ziel ist es nicht "irgendwas anzeigen", sondern über die prüfungen zu "das richtige anzeigen" zu gelangen

 

[Engywuck]

- wer debug output anschaltet darf sich nicht wundern wenn er auch welchen bekommt

Ich beschwere mich ja nicht darüber, dass ich welchen bekomme - aber die Tatsache, dass ich vor der Umstellung keinen bekomme und nach der Umstellung jede Menge, lässt mich stutzig werden. Schließlich hat mein Profil ja auch vor der Umstellung super funktioniert und kann deshalb nicht komplett fehlerhaft sein.

- sollten exceptions ausgegeben werden ohne dass ein if (Global.getPref().debug) davor steht würde ich das allerdings auch als bug ansehen

Ich fände eine zweite Log-Methode schön, die nur dann zuschlägt, wenn debug=true.

- eingaben sind grundsätzlich nicht vertrauenswürdig, egal woher sie stammen (das betrifft natürlich erst mal die importer)

Ok.

- der cacheholder selber ist streng genommen auch ein importer

Anderer Meinung.

- würde ich die daten im cacheholder aber auch bei jedem lesen von v3 vollständig validieren, wäre der gesamte performance vorteil der format umstellung dahin

Ok.

- dadurch enthält das profil nicht vertrauenswürdige daten (wer weiss schon wie der anwender sein index file erzeugt hat ...)

Das mag sein. Aus performance- und übersichtlichkeitsgründen würde ich mich allerdings darauf verlassen. Es ist schließlich nur der Cachewolf, und kein Kernkraftsicherungsprogramm. Der Cachewolf schreibt richtige Daten, und wenn andere Leute falsche Daten reinschreiben, sollte das nicht unser Bier sein und wir unseren Code vollstopfen, um anderer Leute Fehler auszubauen. Meiner Meinung nach ist die index.xml "unsere" Datei und wir sollten uns darauf verlassen können, das die Daten unseren Erwartungen entsprechen.
Hier könnte man zur Sicherheit eine Methode unter "Verwalten" einbauen, die die Daten des Profils prüft.

- also gibt es als "zweite verteidigungslinie" die validierung vor der anzeige, insbesondere im details panel, hier wird dann geprüft ob ich mit den daten die im cache stehen etwas anfangen kann und ggf. eingegriffen, da der overhead bei einer einzelnen anzeige eben deutlich geringer ist als beim einlesen des profils zuzuschlagen
- ziel ist es nicht "irgendwas anzeigen", sondern über die prüfungen zu "das richtige anzeigen" zu gelangen

Bitte immer immer berücksichtigen: Wir haben es hier nicht mit Java zu tun (auch wenn es so aussieht), sondern mit Ewe! Und das Erzeugen von Exceptions ist in "normalen" Programmiersprachen schon teuer, unter Ewe vermutlich erst recht. Daher sollte man Exceptions auf keinen Fall zur Steuerung der Programmlogik verwenden (das ist schon im Normalfall schlechter Stil).
So nebenbei bemerkt, betrifft Deine Antwort aber auch nicht meinen Punkt, auf den Du Dich hier beziehst ;-)

Gruß,
E.

 

[greiol]

- wer debug output anschaltet darf sich nicht wundern wenn er auch welchen bekommt

Ich beschwere mich ja nicht darüber, dass ich welchen bekomme - aber die Tatsache, dass ich vor der Umstellung keinen bekomme und nach der Umstellung jede Menge, lässt mich stutzig werden. Schließlich hat mein Profil ja auch vor der Umstellung super funktioniert und kann deshalb nicht komplett fehlerhaft sein.

don't shoot the messenger.
ein einfaches experiment:
nimm ein v1 profil mit einem tradi, speichern, beenden. nun massierst du die index.xml derart, dass du beim tradi die diff = "" setzt und liest das profil wieder ein. du bekommst zwar keine meldung, aber du hast einen tradi ohne diff was eigentlich nicht sein kann (und ja, die alte version hat sowas tatsächlich unter bestimmten umständen erzeugt). alternativ kannst du einen tradi von hand erzeugen. der hat auch keine brauchbaren werte bis er aktualisiert wurde.

die tatsache, dass die alten versionen keine fehlermeldungen ausgeben, bedeutet nicht, dass keine fehler vorhanden sind.

- sollten exceptions ausgegeben werden ohne dass ein if (Global.getPref().debug) davor steht würde ich das allerdings auch als bug ansehen

Ich fände eine zweite Log-Methode schön, die nur dann zuschlägt, wenn debug=true.

hmm. ich schrieb doch, dass die fehlermeldung nur ausgegeben wird wenn debug auf true steht. ich bin jetzt verwirrt

Hier könnte man zur Sicherheit eine Methode unter "Verwalten" einbauen, die die Daten des Profils prüft.

das ist sicherlich auch eine methode. im moment geht es mir aber vor allem darum herauszufinden welche fehler auftreten (können) und diese möglichst weit vorne abzufangen. das kann ich aber nicht wenn ich sie einfach unter den tisch fallen lasse. genau aus diesem grund brauche ich auch informationen welche eingabedaten die probleme auslösen um vielleicht den migrationsprozess besser gestalten zu können. auch wenn cw keine kraftwerkssteuerung ist, sollten wir doch nicht einfach die augen verschliessen und so tun als wäre alles gut.

Bitte immer immer berücksichtigen: Wir haben es hier nicht mit Java zu tun (auch wenn es so aussieht), sondern mit Ewe! Und das Erzeugen von Exceptions ist in "normalen" Programmiersprachen schon teuer, unter Ewe vermutlich erst recht. Daher sollte man Exceptions auf keinen Fall zur Steuerung der Programmlogik verwenden (das ist schon im Normalfall schlechter Stil).

ich möchte die exceptions auch nicht werfen um der exceptions willen, sondern um herauszufinden wo es im aktuellen datenbestand / migrationsprozess probleme gibt. der normalfall sollte natürlich sein, dass keine exception geworfen wird. eine exception die gar nicht erst geworfen wird, weil wir schon viel früher einen integeren bestand haben, kostet auch keine performance. egal in welcher sprache. richtig schlechter stil ist es fehler zu haben und nicht zu erkennen.

nur mal zur erinnerung: wir sind im entwicklungszweig und suchen fehler, wir sind noch nicht in der nächsten stable

 

[Engywuck]

die tatsache, dass die alten versionen keine fehlermeldungen ausgeben, bedeutet nicht, dass keine fehler vorhanden sind.

Dann müssten aber schon sehr viele Fehler vorhanden gewesen sein... (Aber Du hast ja jetzt schon einiges gemacht. Da muss ich heute Abend mal gucken, wie viel von den Exceptions jetzt überhaupt noch übrig ist.)

hmm. ich schrieb doch, dass die fehlermeldung nur ausgegeben wird wenn debug auf true steht. ich bin jetzt verwirrt

Genau. Ich würde es gerne in eine eigene Methode kapseln. Also neben log noch debuglog, oder so. Information-hiding ist das Zauberwort: Den Verwender der Methode sollte es nicht interessieren, mit welchem Mechanismus abgeprüft wird, ob wir im Debug-Modus sind oder nicht. Er gibt an, ob die Logausgabe für den Debug-Zweck gedacht ist - das ermitteln, ob ein Debug-Zustand vorhanden ist oder nicht, macht die Methode selber.

im moment geht es mir aber vor allem darum herauszufinden welche fehler auftreten (können) und diese möglichst weit vorne abzufangen.
[...]
nur mal zur erinnerung: wir sind im entwicklungszweig und suchen fehler, wir sind noch nicht in der nächsten stable

Aaaah, ok. Derzeit ist also noch Code drin, den Du eher zum debuggen benötigst, damit der Wolf geschwätziger ob der Fehler ist? Wenn das so ist, bin ich einverstanden.

Ansonsten aber würde ich dafür plädieren, eher auf Performance als auf lupenrein saubere Daten zu achten. Wenn jemand einen Tradi anlegt und nicht aktualisiert, hat dieser zwar keine Angaben zur Größe, aber damit würde ich leben, wenn ich stattdessen darauf verzichten kann, für jeden Cache beim Einlesen zu prüfen, ob denn die Werte für Größe, Schwierigkeit etc. wirklich richtig sind:

	private void long2byteFields(long value) {
		setHard(byteFromLong(value, 1));
		setTerrain(byteFromLong(value, 2));
		setType(byteFromLong(value, 3));
		setCacheSize(byteFromLong(value, 4));
		setNoFindLogs((byteFromLong(value, 5)));
		if (( getHard() == -1 || getTerrain() == -1 || getCacheSize() == -1 ) || getType() == -1 ) {
			setIncomplete(true);
		}
	}

Das letzte IF mag ok sein zum debuggen, in regulärer Produktivumgebung finde ich diesen Test jedoch höchst überflüssig: Der zu erwartende Gewinn an Datenreinheit steht in keinem Verhältnis zum zusätzlichen Aufwand, der jedes Mal beim Lesen des Profils geleistet werden muss.

Gruß,
E.

 

[greiol]

hmm. ich schrieb doch, dass die fehlermeldung nur ausgegeben wird wenn debug auf true steht. ich bin jetzt verwirrt

Genau. Ich würde es gerne in eine eigene Methode kapseln. Also neben log noch debuglog, oder so. Information-hiding ist das Zauberwort: Den Verwender der Methode sollte es nicht interessieren, mit welchem Mechanismus abgeprüft wird, ob wir im Debug-Modus sind oder nicht. Er gibt an, ob die Logausgabe für den Debug-Zweck gedacht ist - das ermitteln, ob ein Debug-Zustand vorhanden ist oder nicht, macht die Methode selber.

das kann man so oder so betrachten. einen kritischen zustand sollte die methode auf alle fälle ausgeben. eine debug information imho nur auf explizite anforderung. persönlich würde ich zum loggen lieber log4j nehmen da man das logging noch granularer lösen könnte, aber es läuft ohnehin nicht mit ewe und wäre ohnehin vermutlich auf einem pocketpc zu inperformant.

im moment geht es mir aber vor allem darum herauszufinden welche fehler auftreten (können) und diese möglichst weit vorne abzufangen.
[...]
nur mal zur erinnerung: wir sind im entwicklungszweig und suchen fehler, wir sind noch nicht in der nächsten stable

Aaaah, ok. Derzeit ist also noch Code drin, den Du eher zum debuggen benötigst, damit der Wolf geschwätziger ob der Fehler ist? Wenn das so ist, bin ich einverstanden.

ziel ist es schon nach der migration oder nach dem spidern einen zustand zu haben in dem 99+.x% aller probleme bereits abgefangen und gelöst wurden. es kann dann zwar immer noch eine exception auftreten, aber ab und an sollten wir das abkönnen. derezit gehe ich noch davon aus, dass ein try {} catch {} besser sein dürfte, als ein if (wertistok) { setzewert } else { setzefehler } bzw. if (wertistok) { zeigewert } else { zeigewasanderes }. aber das könnte man natürlich auch mal messen.

Ansonsten aber würde ich dafür plädieren, eher auf Performance als auf lupenrein saubere Daten zu achten.

ich würde gerne so viel wie möglich von beidem haben wollen. dieses ziel zu erreichen ist die aktuelle herausforderung.

Wenn jemand einen Tradi anlegt und nicht aktualisiert, hat dieser zwar keine Angaben zur Größe, aber damit würde ich leben, wenn ich stattdessen darauf verzichten kann, für jeden Cache beim Einlesen zu prüfen, ob denn die Werte für Größe, Schwierigkeit etc. wirklich richtig sind:

	private void long2byteFields(long value) {
		setHard(byteFromLong(value, 1));
		setTerrain(byteFromLong(value, 2));
		setType(byteFromLong(value, 3));
		setCacheSize(byteFromLong(value, 4));
		setNoFindLogs((byteFromLong(value, 5)));
		if (( getHard() == -1 || getTerrain() == -1 || getCacheSize() == -1 ) || getType() == -1 ) {
			setIncomplete(true);
		}
	}

Das letzte IF mag ok sein zum debuggen, in regulärer Produktivumgebung finde ich diesen Test jedoch höchst überflüssig: Der zu erwartende Gewinn an Datenreinheit steht in keinem Verhältnis zum zusätzlichen Aufwand, der jedes Mal beim Lesen des Profils geleistet werden muss.

korrekt. die perfekte stelle das z.b. abzufangen wäre nach dem manuellen anlegen eines tradis direkt diese "fehler" abzufangen und auch auf incomplete zu erkennen. das würde auch meinem ansinnen die eingangskanäle zur prüfung zu nutzen am nächsten kommen. dann kann der user sich überlegen ob er mit der warnung leben möchte oder nicht. da der teil des codes leider noch fehlt bekommt er die warnung (noch) auf einem anderen weg.

die wichtigsten stellen an denen ich nachher eine prüfung haben möchte sind halt die importer (gpx, ocxml, spider) und die reaktion auf änderungen des benutzers im details panel. wenn die eingangskanäle "sauber" sind, dürfte wenig an fehlern übrig bleiben.

 

[Engywuck]

Derezit gehe ich noch davon aus, dass ein try {} catch {} besser sein dürfte, als ein if (wertistok) { setzewert } else { setzefehler } bzw. if (wertistok) { zeigewert } else { zeigewasanderes }. aber das könnte man natürlich auch mal messen.

Da das eine eine einfache Abfrage ist, das andere aber ein (mehr oder weniger komplexes) Objekt erzeugt, nehme ich schwer an, dass das Erzeugen des Exception-Objektes auf jeden Fall die langsamere Variante ist. Es sei denn, man hat sehr viele oder teure Vergleiche... Siehe auch hier: http://tinyurl.com/2p6jd9 (ab "When should I use exceptions?")

Gruß,
E.

 

[greiol]

Derezit gehe ich noch davon aus, dass ein try {} catch {} besser sein dürfte, als ein if (wertistok) { setzewert } else { setzefehler } bzw. if (wertistok) { zeigewert } else { zeigewasanderes }. aber das könnte man natürlich auch mal messen.

Da das eine eine einfache Abfrage ist, das andere aber ein (mehr oder weniger komplexes) Objekt erzeugt, nehme ich schwer an, dass das Erzeugen des Exception-Objektes auf jeden Fall die langsamere Variante ist. Es sei denn, man hat sehr viele oder teure Vergleiche... Siehe auch hier: http://tinyurl.com/2p6jd9 (ab "When should I use exceptions?")

mir ist klar, dass das erzeugen der exception teuer ist, aber die frage war in meinen augen:

is es teurer in 100% aller fälle eine abfrage zu machen oder in x% (x <<< 100) eine exception zu erzeugen und abzufangen?

genau das ist eine der fragen die der genannte artikel auch stellt. es ist an der stelle tatsächlich eine frage der (angenommen) häufigkeit. ich denke auch, dass hier eine unterscheidung angebracht sein könnte zwischen dem was ein rein statisches konverterobjekt zu leisten hat und im stande ist zu leisten im gegenssatz zu dem was ich von einer objektinstanz erwarten würde. aber es ist zumindest ein diskussionwürdiges problem.

case 2 aus "How do I best use exceptions?" haben wir übrigends auch noch an ein paar stellen im code verbuddelt.

 

[greiol]

is es teurer in 100% aller fälle eine abfrage zu machen oder in x% (x <<< 100) eine exception zu erzeugen und abzufangen?

es sieht so aus als hätten wir einen sieger. aber ich schau mir das versuchssetup nochmal an

 

[d0wnl0rd]

Eine Sache, die mir noch in der 1846 aufgefallen ist:
habe ich einen Cache bereits gefunden, aber noch nicht geloggt (Status "Gefunden"), und bügele über mein Profil eine PQ drüber, so bleibt zwar der Status erhalten, aber die Farbgebung (grün vs. weiß) stimmt nicht mehr.
Gruß, d0wnl0rd

 

[greiol]

Eine Sache, die mir noch in der 1846 aufgefallen ist:
habe ich einen Cache bereits gefunden, aber noch nicht geloggt (Status "Gefunden"), und bügele über mein Profil eine PQ drüber, so bleibt zwar der Status erhalten, aber die Farbgebung (grün vs. weiß) stimmt nicht mehr.

das dürfte auch bei alten versionen der fall sein. beim import wird nur das gefunden-flag ggf. korrigiert, während es sich auch sicht des importers beim status eher um ein notizfeld handelt. hmmm

 

[Engywuck]

Habe jetzt noch ein paar kleine Fehler beim Laden von v1 und v2-Profilen gefixt. Jetzt geht das Dateiladen bei mir ohne Probleme. Lediglich die Caches im v2-Profil, deren Größe auf "Not chosen" stand, wurde in v2 nicht korrekt abgespeichert - diese bekommen den Totenkopf und müssen aktualisiert werden.
Bezüglich Addis und Custom Waypoints habe ich im v1 und v2 - Ladevorgang sinnvolle Werte für Schwierigkeit, Terrain und Größe gesetzt, wenn die gefundenen Kappes waren.

Gruß,
E.

 

[greiol]

Hier die Messung am Beispiel Terrain / Difficulty:

zunächste habe ich CacheTerrDiff um eine Funktion erweitert:

	public static final boolean isValidTD(byte td) {
		switch (td) {
		case CW_DT_10: return true;
		case CW_DT_15: return true;
		case CW_DT_20: return true;
		case CW_DT_25: return true;
		case CW_DT_30: return true;
		case CW_DT_35: return true;
		case CW_DT_40: return true;
		case CW_DT_45: return true;
		case CW_DT_50: return true;
		default: return false;
		}
	}

und dann folgenden code in CacheWolf eingefügt der im wesentlichen das gleiche Ergebnis bringen sollte:

long max = 100000000;
String dummy;
byte terr;
ewe.util.Random rnd = new ewe.util.Random();
Vm.debug("check with if");
for (int fehler = 0 ; fehler <= 100; fehler=fehler+10) {
  long start = new Time().getTime();
  for (long j=0;j<max/100*(100-fehler);j++) {
    terr = (byte) (rnd.nextInt(5)*10);
    if (CacheTerrDiff.isValidTD(terr)) {
      dummy = CacheTerrDiff.longDT(terr);
    } else {
      dummy = "";
    }
  }
  for (long j=0;j<max/100*fehler;j++) {
    terr = (byte) (rnd.nextInt(5)*-10);
    if (CacheTerrDiff.isValidTD(terr)) {
      dummy = CacheTerrDiff.longDT(terr);
    } else {
      dummy = "";
    }
  }
  long end = new Time().getTime();
  Vm.debug(fehler+"% fehler "+(end-start)+" ms");
}

Vm.debug("check with exception");
for (int fehler = 0 ; fehler <= 100; fehler=fehler+10) {
  long start = new Time().getTime();
  for (long j=0;j<max/100*(100-fehler);j++) {
    terr = (byte) (rnd.nextInt(5)*10);
    try {
      dummy = CacheTerrDiff.longDT(terr);
    } catch (IllegalArgumentException ex) {
      dummy = "";
    }
  }
  for (long j=0;j<max/100*fehler;j++) {
    terr = (byte) (rnd.nextInt(5)*-10);
    try {
      dummy = CacheTerrDiff.longDT(terr);
    } catch (IllegalArgumentException ex) {
      dummy = "";
    }
  }
  long end = new Time().getTime();
  Vm.debug(fehler+"% fehler "+(end-start)+" ms");
}

Falls der Messcode keinen grundsätzlichen Fehler hat der die Vergleichbarkeit gefährdet ist das das Ergebnis (zur leichteren Lesbarkeit 1000er punkte eingefügt):

check with if
0% fehler 14.226 ms
10% fehler 13.820 ms
20% fehler 14.604 ms
30% fehler 13.190 ms
40% fehler 19.110 ms
50% fehler 34.946 ms
60% fehler 32.576 ms
70% fehler 34.034 ms
80% fehler 32.456 ms
90% fehler 32.832 ms
100% fehler 30.402 ms
check with exception
0% fehler 346.616 ms
10% fehler 474.716 ms
20% fehler 494.160 ms
30% fehler 729.886 ms
Abbruch

Ich gestehe das Ergebnis hat mich in seiner Deutlichkeit doch etwas überrauscht auch wenn vermutlich niemand jemals 100.000.000 Caches parsen wird

Ergebnis: Umbau von Exceptions auf Abfrage. Exceptions nur noch für die, die auf den Vergleich aus irgend einem Grund verzichten möchten.

edit: ergebnisse wurden mit der java version ohne eclipse gemessen

 

[Engywuck]

Diese Deutlichkeit überrascht mich dann auch etwas ;-) Aber man verschätzt sich da gerne: Ein Vergleich ist schnell gemacht, ein paar Bits schieben und manipulieren, und schwups ist das Ergebnis da. Wenn man aber ein Objekt erzeugen will, da muss man beim Speichermanager speicher anfragen, der muss gucken, ob und wo was frei ist, der Speicher muss reserviert und belegt werden und nachher wieder freigegeben - und all dies mit ewe, was hier nicht sehr performant ist.

Die Ergebnisse sollten uns noch einmal dazu anhalten, das massenweise Erzeugen von Objekten zu vermeiden so gut es geht.

Gruß,
E.

Edit: Du hast Deine Messungen vermutlich mit Eclipse gemacht. Da läuft natürlich Java mit dem Java-Speichermanager unter der Haube (denke ich). Wenn man die Exe nimmt und Ewe werkeln lässt, werden die Ergebnisse vermutlich noch frappanter...

 

[huzzel]

Gibt es im neuen Datenformat bei der Cachegröße einen Unterschied zwischen "None" und "Not chosen".
Wenn mich mein Programm nicht veräppelt, ist es beim neuen Format beides mal "0", richtig? Wenn ja, es ist aber schon ein Unterschied zwischen "None" (da ist nix) und "Not chosen" (da ist irgendwas).