hi,

Klar geht's schneller. Wenn die zu durchsuchenden Daten vorverarbeitet in einer Datei liegen, schreibt man die Datei nicht sequenziell sondern als B-Tree.

Dateien werden immer sequentiell geschrieben. Was meine Daten betrifft: Das sind Schlüssel-Werte-Paare wobei auf einen Schlüssel mehrere Attribute fallen mit den dazugehörigen Werten.

In meiner Datei liegen diese Tupel nach Schlüssel sortiert vor, haben jedoch keine feste Länge. Da man beim Lesen die Länge aber wissen muss, ist die natürlich vor jedem Tupel als Offset angegeben.

Diese Daten als B-Tree abzulegen macht keinen Sinn, weil sich die daraus zu erzeugenden Hierarchien erst aus dem Inhalt ergeben und sehr vielgestaltig sein können.

Dennoch gibt es Möglichkeiten zur Optimierung die sich z.B. die Sortierung zunutze machen. So kann man z.b. die Speicheradresse ermitteln an welcher ein Schlüssel (Entity) das erstemal auftritt, muss also nicht jedesmal von vorn beginnen. Und da C die Daten unfragmentiert im Hauptspeicher hält, ergeben sich solche Zeiger ja aus dem Offset der ohnehin in der Datei selbst kodiert ist.

Das nutze ich bereits, aber merklich bringt's bei meinen Datenmengen nichts. Denn die Performance ist auch ohne Optimierung schon so überwältigend, daß ich über Optimierungen nur nachdenke wenn's mir langweilig wird 😉

MfG

freiwillige Angabe, für jeden sichtbar
freiwillige Angabe, für jeden sichtbar
freiwillige Angabe, für jeden sichtbar

Vorschau (Nachricht wird im Forum „SELF-Forum“ erscheinen)

  • Keine Tag-Vorschläge verfügbar
  • keine Tags vergeben

abbrechen