Ich bräuchte eure Hilfe bzgl. der richtigen Auswahl eines Containers.

Kurz zum Iststand:
Es wird in einem sehr alten Sourcecode eine Art Fernseh-Sendungsprogamm mittels einer selbstgebauten doppeltverketteten Liste abgebildet. Zustäzlich gibt es auch einen Baum (key = Beginndatum der Sendung) und als Datenobjekt der Pointer auf das Listenobjekt.
Der Vorteil dabei war/ist, dass man mittels dem Baum schnell auf ein gewünschtes Datum springen kann und da das gelieferte Objekt auch alle Daten (next/prev pointer) für die Navigation in der doppeltverketteten Liste hat, war eine weitere Navigation in dieser Liste auch sehr schnell (weil man zb. die nächsten 20 Einträge zurückliefern muss).

Kann man das ganze auch irgendwie mit Containern aus der STL oder boost auch abbilden?
Weil mit einer std::map alleine bin ich beim weiteren durchiterieren eher sehr langsam und eine Kombination mit std::vector ist mir leider nicht bekannt.

Ich freue mich auf eure Vorschläge!

vg Johannes

Es wird in einem sehr alten Sourcecode eine Art Fernseh-Sendungsprogamm mittels einer selbstgebauten doppeltverketteten Liste abgebildet. Zustäzlich gibt es auch einen Baum (key = Beginndatum der Sendung) und als Datenobjekt der Pointer auf das Listenobjekt.
Der Vorteil dabei war/ist, dass man mittels dem Baum schnell auf ein gewünschtes Datum springen kann und da das gelieferte Objekt auch alle Daten (next/prev pointer) für die Navigation in der doppeltverketteten Liste hat, war eine weitere Navigation in dieser Liste auch sehr schnell (weil man zb. die nächsten 20 Einträge zurückliefern muss).

Der stl-Baum kann schnell durchiterieren! Dazu bauen sie extra noch Aufwärtszeiger ein. Brauchst den Trick mit der parallelen Liste überhaupt nicht.

taff schrieb:

Es wird in einem sehr alten Sourcecode eine Art Fernseh-Sendungsprogamm mittels einer selbstgebauten doppeltverketteten Liste abgebildet. Zustäzlich gibt es auch einen Baum (key = Beginndatum der Sendung) und als Datenobjekt der Pointer auf das Listenobjekt.
Der Vorteil dabei war/ist, dass man mittels dem Baum schnell auf ein gewünschtes Datum springen kann und da das gelieferte Objekt auch alle Daten (next/prev pointer) für die Navigation in der doppeltverketteten Liste hat, war eine weitere Navigation in dieser Liste auch sehr schnell (weil man zb. die nächsten 20 Einträge zurückliefern muss).

Der stl-Baum kann schnell durchiterieren! Dazu bauen sie extra noch Aufwärtszeiger ein. Brauchst den Trick mit der parallelen Liste überhaupt nicht.

Dann muss man aber den Baum hoch und runterlaufen. Das geht sicher auch schnell... ist aber halt ein anderes schnell.

nwp3 schrieb:

Einen vector nehmen, nach Datum sortieren, per lower_bound nach Einträgen suchen. Weitere Navigation ist einfach wie bei der Liste und es gibt keinen Overhead durch next/prev-Pointer und Cache-Misses. Wenn du ständig tausende Fernsehprogramme einfügst und löschst ohne was zu suchen könnte es inperformant werden.

Ja so ist es, dass ständig Einträge gelöscht/geändert/eingefügt werden.

Jester schrieb:

Du könntest boost::intrusive benutzen, damit kannst du die pointer der datenstruktur direkt mit in den daten ablegen, und so jederzeit wenn du daten in der hand hast auch auf von dort aus in der entsprechenden datenstruktur navigieren. Einen suchbaum mit Liste zum iterieren lässt sich da relativ leicht bauen.

Irgendwie tue ich mir bisserl schwer, das konzept von boost::intrusive zu verstehen. Also ich ersetze damit den Baum aber nicht die Liste?

volkard schrieb:

Der stl-Baum kann schnell durchiterieren! Dazu bauen sie extra noch Aufwärtszeiger ein. Brauchst den Trick mit der parallelen Liste überhaupt nicht.

Ein Test liefert mir folgendes Ergebnis: Vector und Map besitzen jeweils 2000 Elemente. Beide Container werden mittels iterator von begin bis end durchgelaufen. Es ist dann doch ein unterschied bemerkbar, überhaupt wenn man das durchlaufen statt einmal 100mal macht (vec:0,07sec zu map:0,09sec)
Oder muss ich einen bestimmten map-Iterator verwenden?

Furble Wurble schrieb:

Sind denn die Einträge in der Liste auch nach Datum sortiert?
Oder was sind die "nächsten 20 Einträge", wenn ich von einem beliebigen Element starte?

Ja jetzt ist die Liste auch sortiert, wobei ich mir das doppelte sortieren gerne sparen möchte.

Ein Test liefert mir folgendes Ergebnis: Vector und Map besitzen jeweils 2000 Elemente. Beide Container werden mittels iterator von begin bis end durchgelaufen. Es ist dann doch ein unterschied bemerkbar, überhaupt wenn man das durchlaufen statt einmal 100mal macht (vec:0,07sec zu map:0,09sec)
Oder muss ich einen bestimmten map-Iterator verwenden?

Nee, war schon richtig. Ein wenig langsamer ist die map ohne Liste beim reinen Durchrennen. Dafür aber beim Einfügen und Löschen fast doppelt so schnell.

taff schrieb:

Ein Test liefert mir folgendes Ergebnis: Vector und Map besitzen jeweils 2000 Elemente. Beide Container werden mittels iterator von begin bis end durchgelaufen. Es ist dann doch ein unterschied bemerkbar, überhaupt wenn man das durchlaufen statt einmal 100mal macht (vec:0,07sec zu map:0,09sec)
Oder muss ich einen bestimmten map-Iterator verwenden?

Nee, war schon richtig. Ein wenig langsamer ist die map ohne Liste beim reinen Durchrennen. Dafür aber beim Einfügen und Löschen fast doppelt so schnell.

Huch, warum sollte sie das denn sein? Ich muss doch beim Einfügen das nächstkleinere Element (oder das nächstgrößere) sowieso bestimmen und kann mich dort dann durch umbiegen von einer Hand voll Zeigern in die Liste einhängen. Wo bezahle ich da denn einen Faktor 2?

@taff: damit müsstest Du schon beide Datenstrukturen ersetzen: Baum und Liste. Ich glaube aber auch nicht, dass für Deine Anwendung der Performancegewinn wirklich groß bist. Und bevor Du jetzt ewig brauchst würde ich's einfach mal mit ner map machen. Wenn Du alles schön kapselst kannst Du die Datenstruktur dann ja irgendwann mal ersetzen wenn sich rausstellen sollte, dass es wirklich nicht schnell genug ist.

Dein Vergleich ist auch nicht ganz fair, weil Du vector mit map vergleichst, du solltest wenn aber eher list mit map vergleichen. Ich glaube nicht, dass Du mit derart kleinen Elementzahlen da einen großen Unterschied sehen wirst.

Huch, warum sollte sie das denn sein? Ich muss doch beim Einfügen das nächstkleinere Element (oder das nächstgrößere) sowieso bestimmen und kann mich dort dann durch umbiegen von einer Hand voll Zeigern in die Liste einhängen. Wo bezahle ich da denn einen Faktor 2?

Gar nicht, hatte das intrusive nicht mehr im Sinn. Ich denke, er zahlt eh fast nur für new/delete.

Was wird wohl die Anzeige auf den Bildschirm kosten im Vergleich zum Durchlaufen?