Reihenfolge der Caches in der MyFindsPQ

[Nachtfalke]

Weiss zufällig jemand, ob die Reihenfolge der Caches in der eigenen MyFindsPQ immer gleich ist?

 

[Kalli]

Hat mich noch nie gekümmert. Wofür ist den die Reihenfolge wichtig?

 

[radioscout]

Die Reihenfolge kann interessant sein, wenn eine PQ an die 1000-Caches-Grenze stößt und man wissen will, welche Dosen fehlen.

 

[Nachtfalke]

Hat mich noch nie gekümmert. Wofür ist den die Reihenfolge wichtig?

Normalerweise ist sie unwichtig. Interessant wird sie, wenn man versucht, in einem Programm immer nur das Delta zur letzten Version zu importieren.

Die Reihenfolge kann interessant sein, wenn eine PQ an die 1000-Caches-Grenze stößt und man wissen will, welche Dosen fehlen.

Seit wann ist die myFinds-PQ auf 1000 Caches begrenzt?

 

[TeamAdolzfurt]

Aus Erfahrung kann ich nur sagen: wer sich auf nicht dokumentierte (und garantierte!) Eigenschaften irgendwelcher Daten verlässt, ist verlassen. Sowas kann sich ohne Vorwarnung ändern. Das haben schon unzählige Entwickler verflucht, die z.B. zufällige Reihenfolgen auf irgendwelche SQL-Ausgaben als gegeben angenommen haben (nach dem Motto: ich hab zwar kein Sortierkriterium auf Feld x, das kommt aber immer in der Reihenfolge des Einlesens oder so). Das knallt dann in dem Moment, in dem der B-Baum sich ändert, weil es ein Insert nach einem Delete gab... nix ist mehr mit "Ausgabe folgt Reihenfolge der Eingabe, ohne daß ich das erzwungen habe" und ruft dann herbes Erstaunen hervor.

Der tiefere Sinn erschliesst sich mir auch nicht. So eine MyFinds hat maximal ein paar tausend Einträge mit einem Primärschlüssel... das ist eine sehr überschaubare Datenmenge. Was soll die Ersparnis sein, sich auf ein (unbekanntes und unbeeinflussbares) Sortierkriterium des PQ-Generators bei GC zu verlassen und nur Teile einzulesen?

MaJa

 

[Nachtfalke]

Aus Erfahrung kann ich nur sagen: wer sich auf nicht dokumentierte (und garantierte!) Eigenschaften irgendwelcher Daten verlässt, ist verlassen. Sowas kann sich ohne Vorwarnung ändern. Das haben schon unzählige Entwickler verflucht[..]

Genau deswegen frage ich ja.

Der tiefere Sinn erschliesst sich mir auch nicht. So eine MyFinds hat maximal ein paar tausend Einträge mit einem Primärschlüssel... das ist eine sehr überschaubare Datenmenge. Was soll die Ersparnis sein, sich auf ein (unbekanntes und unbeeinflussbares) Sortierkriterium des PQ-Generators bei GC zu verlassen und nur Teile einzulesen?

Performance. Wenn man statt mehrerer tausend Einträge pro Lauf nur noch im Höchstfall ein paar Dutzend einlesen muß, dürfte das schon einen Unterschied machen.

 

[TeamAdolzfurt]

Performance. Wenn man statt mehrerer tausend Einträge pro Lauf nur noch im Höchstfall ein paar Dutzend einlesen muß, dürfte das schon einen Unterschied machen.

Der Performance-Aspekt ist schon klar. Ich hab gerade mal ein kleines Perl-Programm ausprobiert, das ich zu anderen Zwecken gerade rumliegen hatte. Das liest ein beliebiges Textfile von stdin, parsed das (hoffentlich) enthaltene xml und baut eine assoziatives Array auf, das die xml-Struktur und Inhalte wiederspiegelt. Mit meinem aktuellen MyFinds (rund 650 Finds) dauert das auf einen Popel-Notebook runde 6s.

Klar, sowas summiert sich. Allerdings ist diese Statistik-Generierung sowieso mehr ein Batchjob, das macht man doch nicht täglich. Andererseits ein klarer Beweis, daß GUI-zentrierte Entwicklung (und die dazugehörigen Tools) schlicht nicht für alles ideal sein müssen.

MaJa

 

[Kalli]

Performance. Wenn man statt mehrerer tausend Einträge pro Lauf nur noch im Höchstfall ein paar Dutzend einlesen muß, dürfte das schon einen Unterschied machen.

Naja, wir sprechen hier von XML-Dateien, da nimmt man doch normalerweise eh einen Parser, der sich dass ganze File reinzieht. Ab einer gewissen Zeile zu beginnen, dürfte eh keinen Sinn machen, da sich ja auch Beschreibungen ändern können, mal davon abgesehen, dass dies ein XML-Parser eh nicht packt, weil die Struktur nicht mehr passt. Auf die Reihenfolge würde ich mich auch nicht verlassen.