Inwiefern ist dieser Faktor "slower" zu bewerten? Wenn ich nun eine Datenstruktur suche, die mir auf einer statischen Datenbasis möglichst schnelles Suchen ermöglicht, ist dann ein AVL-Baum der Baum meiner Wahl? Ist das "slower" so gering, dass ich eventuell nur einen RB-Tree implementiere und selbst für stark suchlastige Anwendungen einen RB-Tree verwende?

Warum verwendet sowohl Java als auch meine C++-STL-Implementation einen RB-Tree als Map-Implementation? Sind sie generell als schneller zu bewerten im Vergleich zu AVL-Bäumen?

MfG SideWinder

MfG SideWinder

... but it turns
out that in the real world, RB-trees have some advantages. Of course,
the primary benefit of an AVL tree is that it is always optimally
balanced. That is, you cannot create a binary tree that is more
balanced than an equivalent AVL tree, which means that you always get
the fastest search time, in terms of number of nodes visited.

Unfortunately, AVL trees typically do not contain a parent pointer,
which means that traversal is slower than with an RB-tree that has
parent pointers. That's because traversing to a sibling node requires
starting over at the root, rather than only moving up the tree as far
as you need to.

The other factor is that AVL trees are actually a bit *too* balanced.
Because they maintain the optimal balance for any given tree, they
perform rotations more often than is necessary to get good balanced
tree operation. So even though one side of an RB tree may be twice
as high as the other side, this imbalance is paid for in the reduced
number of rotations on insert and removal operations. Of course, in
specific applications, one design might be always better than the
other, but in general, these are the major reasons why RB-trees are
favored over AVL trees. If I recall, the rotations in an RB-tree are
slightly simpler because there are fewer cases to consider, but I
think it is a very minor advantage.

Unfortunately, AVL trees typically do not contain a parent pointer,
which means that traversal is slower than with an RB-tree that has
parent pointers. That's because traversing to a sibling node requires
starting over at the root, rather than only moving up the tree as far
as you need to.

Zumindest das einfache Durchlaufen der Elemente kann man aber trotzdem hinkriegen, indem man den Blätter noch nen next und previous pointer verpaßt und so die Blätter in ne Liste aufnimmt. Praktischerweise muß man beim rotieren diese Liste nicht umordnen. Auch die Suche nach dem größten bzw. kleinsten Element wird so in konstanter Zeit möglich.

RB-Trees scheinen mir ja auf Grund ihres geringeren Aufwands bei Insert/Delete für stark dynamische Datenstrukturen eine Option zu sein.

MfG SideWinder

Wenn du total statische Daten hast, kannst du sowieso erstmal noch viel mehr Aufwand betreiben, um die Datenstrukturen aufzubauen. Für das reine Suchen eine Hashtable, für größer/kleiner suchen einen AVL-Baum oder bei riesigen Datenmengen einen B-Baum, der die Cache-Größen berücksichtigt.

Du kannst aber auch einfach die std::map benutzen und das wird dann schon passen.

BR
Vinzenz

Unfortunately, AVL trees typically do not contain a parent pointer,
which means that traversal is slower than with an RB-tree that has
parent pointers. That's because traversing to a sibling node requires
starting over at the root, rather than only moving up the tree as far
as you need to.

das ist doch ein implementierungsdetail, meine avl-tree node schaut so aus von den membern her:

T*				m_pLeft;
	T*				m_pRight;
	T*				m_pParent;
	DSINT			m_Height;

dadurch ist sie bei 32bit systemen auf 32byte alligned und bei 64bit systemen auf 64byte.

Bei einem test, bei dem ich bei hunderttausenden dreiecken die eckpunkte mergen möchte, indem ich, falls ein eckpunkt noch nicht in der map vorhanden ist, den neu in die map stecke, ist mein AVL ca 30% fixer als die map der STL-port und ca 20% fixer als die map von der microsoft stl.

meiner persönlichen überlegung nach ist ein AVL-tree schneller, weil:
- ist schneller beim durchsuchen
- langsammer beim einfügen
da aber zum einfügen erstmal die richtige position "gesucht" wird, hebt sich das paar mal mehr rotieren gegen die suchdauer auf.
- löschen? da eine node weiß wo sie steckt, dürfte die zeit dabei konstant sein (natürlich kommt rotieren hinzu)

Ich habe jetzt erstmal einen RB-Tree implementiert, da ich den sowieso noch nicht gekannt habe und mich so gut einarbeiten kann und zweitens sich die Entwickler der JavaVM und der einzelnen STL-Ports sicher auch Gedanken gemacht haben.

Rapsos Überlegungen stimmen dann ja wohl eher für große Bäume wo ein Höhenunterschied von Faktor 2 sich ordentlich auf die Performance auswirken kann. Bei Bäumen bis zu 50 Elementen würde ich aber doch dem RB-Tree den Vorrang geben. Die 3 Such-Schleifen-Durchläufe mehr machen imho den Rotationsaufwand nicht wett.

MfG SideWinder

Bei mir sieht das noch so aus:

Element data; // sizeof(Element)
Node* up; // 32 Bit
Node* left; // 32 Bit
Node* right; // 32 Bit
Bool color; // 8 Bit

Wäre folgendes besser?

Element* data; // 32 Bit
Node* up; // 32 Bit
Node* left; // 32 Bit
Node* right; // 32 Bit
Int color; // 32 Bit;

MfG SideWinder

MfG SideWinder

du solltest immer versuchen zumindestens 32bit zu allignen, 32byte is schon optimal für die meisten cpus.
wenn du immer auf 32bit allignst, dann könntest du die untersten bits der pointer als deinen bool für Red/Black nehmen und würdest auch ein wenig speicher sparen, was am ende fixer sein kann.

und ja, für 50 elemente könnte ein R/B vielleicht schneller sein, vielleicht ist das rotieren aber auch nicht so teuer dass ein AVL fixer ist. aber so kleine dinge (50 elemente) sind meistens nicht performancerelavant und wenn doch, dann kann man sich speicherintensivere systeme ausdenken die besser als O(log n) sind ;).