Red–black tree

In 1972, Rudolf Bayer[5] invented a data structure that was a special order-4 case of a B-tree. These trees maintained all paths from root to leaf with the same number of nodes, creating perfectly balanced trees. However, they were not binary search trees. Bayer called them a "symmetric binary B-tree" in his paper and later they became popular as 2–3–4 trees or just 2–4 trees.[6]

In a 1978 paper, "A Dichromatic Framework for Balanced Trees",[7] Leonidas J. Guibas and Robert Sedgewick derived the red–black tree from the symmetric binary B-tree.[8] The color "red" was chosen because it was the best-looking color produced by the color laser printer available to the authors while working at Xerox PARC.[9] Another response from Guibas states that it was because of the red and black pens available to them to draw the trees.[10]

In 1993, Arne Andersson introduced the idea of a right leaning tree to simplify insert and delete operations.[11]

In 1999, Chris Okasaki showed how to make the insert operation purely functional. Its balance function needed to take care of only 4 unbalanced cases and one default balanced case.[12]

The original algorithm used 8 unbalanced cases, but Cormen et al. (2001) reduced that to 6 unbalanced cases.[3] Sedgewick showed that the insert operation can be implemented in just 46 lines of Java code.[13][14] In 2008, Sedgewick proposed the left-leaning red–black tree, leveraging Andersson’s idea that simplified the insert and delete operations. Sedgewick originally allowed nodes whose two children are red, making his trees more like 2–3–4 trees, but later this restriction was added, making new trees more like 2–3 trees. Sedgewick implemented the insert algorithm in just 33 lines, significantly shortening his original 46 lines of code.[15][16]

Example of a red–black tree

Figure 1: ... with explicit NIL leaves

Figure 2: ... with implicit left and right docking points

A red–black tree is a special type of binary search tree, used in computer science to organise pieces of comparable data, such as text fragments or numbers (as e.g. the numbers in figures 1 and 2). The nodes carrying keys and/or data are frequently called "internal nodes", but in order to make this very specific they are also called non-NIL nodes in this article.

The leaf nodes of red–black trees ( NIL  in figure 1) do not contain keys or data. These "leaves" need not be explicit individuals in computer memory: a NULL pointer can —as in all binary tree data structures— encode the fact that there is no child node at this position in the (parent) node. Nevertheless, by their position in the tree, these objects are in relation to other nodes that is relevant to the RB-structure, it may have parent, sibling (i.e., the other child of the parent), uncle, even nephew node; and may be child—but never parent of another node. It is not really necessary to attribute a "color" to these end-of-path objects, because the condition "is NIL or BLACK" is implied by the condition "is NIL" (see also this remark).

Figure 2 shows the conceptually same red–black tree without these NIL leaves. In order to arrive at the same notion of a path, one has to notice that e.g. 3 paths run through the node 1, namely a path through 1_left plus 2 additional paths through 1_right, namely the paths through 6_left and 6_right. This way, these ends of the paths are also docking points for new nodes to be inserted, fully equivalent to the NIL leaves of figure 1.

On the other hand, in order to save a marginal amount of execution time, these (possibly many) NIL leaves may be implemented as pointers to one unique (and black) sentinel node (instead of pointers of value NULL).

As a conclusion, the fact that a child does not exist (is not a true node, does not contain data) can in all occurrences be specified by the very same NULL pointer or as the very same pointer to a sentinel node. Throughout this article, either choice is called NIL node and has the constant value NIL.

The black depth of a node is defined as the number of black nodes from the root to that node (i.e. the number of black ancestors). The black height of a red–black tree is the number of black nodes in any path from the root to the leaves, which, by requirement 4, is constant (alternatively, it could be defined as the black depth of any leaf node).[17]^{: 154–165} The black height of a node is the black height of the subtree rooted by it. In this article, the black height of a NIL node shall be set to 0, because its subtree is empty as suggested by figure 2, and its tree height is also 0.

In addition to the requirements imposed on a binary search tree the following must be satisfied by a red–black tree:[18]

1. Every node is either red or black.
2. All NIL nodes (figure 1) are considered black.
3. A red node does not have a red child.
4. Every path from a given node to any of its descendant NIL nodes goes through the same number of black nodes.

Some authors, e.g. Cormen & al.,[18] claim "the root is black" as fifth requirement; but not Mehlhorn & Sanders[17] or Sedgewick & Wayne.[16]^{: 432–447} Since the root can always be changed from red to black, this rule has little effect on analysis. This article also omits it, because it slightly disturbs the recursive algorithms and proofs.

As an example, every perfect binary tree that consists only of black nodes is a red–black tree.

The read-only operations, such as search or tree traversal, do not affect any of the requirements. On the other hand, the modifying operations insert and delete easily maintain requirements 1 and 2, but with respect to the other requirements some extra effort has to be taken, in order to avoid the introduction of a violation of requirement 3, called a red-violation, or of requirement 4, called a black-violation.

The requirements enforce a critical property of red–black trees: the path from the root to the farthest leaf is no more than twice as long as the path from the root to the nearest leaf. The result is that the tree is height-balanced. Since operations such as inserting, deleting, and finding values require worst-case time proportional to the height ${\displaystyle h}$ of the tree, this upper bound on the height allows red–black trees to be efficient in the worst case, namely logarithmic in the number ${\displaystyle n}$ of entries, i.e. ${\displaystyle h\in O(\log n)}$, which is not the case for ordinary binary search trees. For a mathematical proof see section Proof of bounds.

Red–black trees, like all binary search trees, allow quite efficient sequential access (e.g. in-order traversal, that is: in the order Left–Root–Right) of their elements. But they support also asymptotically optimal direct access via a traversal from root to leaf, resulting in ${\displaystyle O(\log n)}$ search time.

Figure 3: The same red–black tree as in the example above, now as a B-tree

A red–black tree is similar in structure to a B-tree of order[19] 4, where each node can contain between 1 and 3 values and (accordingly) between 2 and 4 child pointers. In such a B-tree, each node will contain only one value matching the value in a black node of the red–black tree, with an optional value before and/or after it in the same node, both matching an equivalent red node of the red–black tree.

One way to see this equivalence is to "move up" the red nodes in a graphical representation of the red–black tree, so that they align horizontally with their parent black node, by creating together a horizontal cluster. In the B-tree, or in the modified graphical representation of the red–black tree, all leaf nodes are at the same depth.

The red–black tree is then structurally equivalent to a B-tree of order 4, with a minimum fill factor of 33% of values per cluster with a maximum capacity of 3 values.

This B-tree type is still more general than a red–black tree though, as it allows ambiguity in a red–black tree conversion—multiple red–black trees can be produced from an equivalent B-tree of order 4 (see figure 3). If a B-tree cluster contains only 1 value, it is the minimum, black, and has two child pointers. If a cluster contains 3 values, then the central value will be black and each value stored on its sides will be red. If the cluster contains two values, however, either one can become the black node in the red–black tree (and the other one will be red).

So the order-4 B-tree does not maintain which of the values contained in each cluster is the root black tree for the whole cluster and the parent of the other values in the same cluster. Despite this, the operations on red–black trees are more economical in time because you don’t have to maintain the vector of values.[20] It may be costly if values are stored directly in each node rather than being stored by reference. B-tree nodes, however, are more economical in space because you don’t need to store the color attribute for each node. Instead, you have to know which slot in the cluster vector is used. If values are stored by reference, e.g. objects, null references can be used and so the cluster can be represented by a vector containing 3 slots for value pointers plus 4 slots for child references in the tree. In that case, the B-tree can be more compact in memory, improving data locality.

The same analogy can be made with B-trees with larger orders that can be structurally equivalent to a colored binary tree: you just need more colors. Suppose that you add blue, then the blue–red–black tree defined like red–black trees but with the additional constraint that no two successive nodes in the hierarchy will be blue and all blue nodes will be children of a red node, then it becomes equivalent to a B-tree whose clusters will have at most 7 values in the following colors: blue, red, blue, black, blue, red, blue (For each cluster, there will be at most 1 black node, 2 red nodes, and 4 blue nodes).

For moderate volumes of values, insertions and deletions in a colored binary tree are faster compared to B-trees because colored trees don’t attempt to maximise the fill factor of each horizontal cluster of nodes (only the minimum fill factor is guaranteed in colored binary trees, limiting the number of splits or junctions of clusters). B-trees will be faster for performing rotations (because rotations will frequently occur within the same cluster rather than with multiple separate nodes in a colored binary tree). For storing large volumes, however, B-trees will be much faster as they will be more compact by grouping several children in the same cluster where they can be accessed locally.

All optimizations possible in B-trees to increase the average fill factors of clusters are possible in the equivalent multicolored binary tree. Notably, maximizing the average fill factor in a structurally equivalent B-tree is the same as reducing the total height of the multicolored tree, by increasing the number of non-black nodes. The worst case occurs when all nodes in a colored binary tree are black, the best case occurs when only a third of them are black (and the other two thirds are red nodes).

Red–black trees offer worst-case guarantees for insertion time, deletion time, and search time. Not only does this make them valuable in time-sensitive applications such as real-time applications, but it makes them valuable building blocks in other data structures that provide worst-case guarantees; for example, many data structures used in computational geometry can be based on red–black trees, and the Completely Fair Scheduler used in current Linux kernels and epoll system call implementation[21] uses red–black trees.

The AVL tree is another structure supporting ${\displaystyle O(\log n)}$ search, insertion, and removal. AVL trees can be colored red–black, thus are a subset of RB trees. Worst-case height is 0.720 times the worst-case height of RB trees, so AVL trees are more rigidly balanced. The performance measurements of Ben Pfaff with realistic test cases in 79 runs find AVL to RB ratios between 0.677 and 1.077, median at 0.947, and geometric mean 0.910.[22] WAVL trees have a performance in between those two.

Red–black trees are also particularly valuable in functional programming, where they are one of the most common persistent data structures, used to construct associative arrays and sets that can retain previous versions after mutations. The persistent version of red–black trees requires ${\displaystyle O(\log n)}$ space for each insertion or deletion, in addition to time.

For every 2–4 tree, there are corresponding red–black trees with data elements in the same order. The insertion and deletion operations on 2–4 trees are also equivalent to color-flipping and rotations in red–black trees. This makes 2–4 trees an important tool for understanding the logic behind red–black trees, and this is why many introductory algorithm texts introduce 2–4 trees just before red–black trees, even though 2–4 trees are not often used in practice.

In 2008, Sedgewick introduced a simpler version of the red–black tree called the left-leaning red–black tree[23] by eliminating a previously unspecified degree of freedom in the implementation. The LLRB maintains an additional invariant that all red links must lean left except during inserts and deletes. Red–black trees can be made isometric to either 2–3 trees,[24] or 2–4 trees,[23] for any sequence of operations. The 2–4 tree isometry was described in 1978 by Sedgewick.[7] With 2–4 trees, the isometry is resolved by a "color flip," corresponding to a split, in which the red color of two children nodes leaves the children and moves to the parent node.

The original description of the tango tree, a type of tree optimised for fast searches, specifically uses red–black trees as part of its data structure.[25]

As of Java 8, the HashMap has been modified such that instead of using a LinkedList to store different elements with colliding hashcodes, a red–black tree is used. This results in the improvement of time complexity of searching such an element from ${\displaystyle O(m)}$ to ${\displaystyle O(\log m)}$ where ${\displaystyle m}$ is the number of elements with colliding hashcodes.[26]

The read-only operations, such as search or tree traversal, on a red–black tree require no modification from those used for binary search trees, because every red–black tree is a special case of a simple binary search tree. However, the immediate result of an insertion or removal may violate the properties of a red–black tree, the restoration of which is called rebalancing so that red–black trees become self-balancing. It requires in the worst case a small number, ${\displaystyle O(\log n)}$ in Big O notation, where ${\displaystyle n}$ is the number of objects in the tree, on average or amortized ${\displaystyle O(1)}$, a constant number,[27]^: 310 [17]^: 158 of color changes (which are very quick in practice); and no more than three tree rotations[28] (two for insertion).

If the example implementation below is not suitable, other implementations with explanations may be found in Ben Pfaff’s[29] annotated C library GNU libavl (v2.0.3 as of June 2019).

The details of the insert and removal operations will be demonstrated with example C++ code. The example code uses the type definitions and macros below, as well as the helper function for rotations:

// Basic type definitions:

enum color_t { BLACK, RED };

struct RBnode {     // node of red–black tree
  RBnode* parent;   // == NULL if root of the tree
  RBnode* child[2]; // == NIL if child is empty
    // Index is:
    //   LEFT  := 0, if (key < parent->key)
    //   RIGHT := 1, if (key > parent->key)
  enum color_t color;
  int key;
};

#define NIL   NULL // null pointer  or  pointer to sentinel node
#define LEFT  0
#define RIGHT 1
#define left  child[LEFT]
#define right child[RIGHT]

struct RBtree { // red–black tree
  RBnode* root; // == NIL if tree is empty
};

// Get the child direction (∈ { LEFT, RIGHT })
//   of the non-root non-NIL  RBnode* N:
#define childDir(N) ( N == (N->parent)->right ? RIGHT : LEFT )

Left rotation and
right rotation, animated.

RBnode* RotateDirRoot(
    RBtree* T,   // red–black tree
    RBnode* P,   // root of subtree (may be the root of T)
    int dir) {   // dir ∈ { LEFT, RIGHT }
  RBnode* G = P->parent;
  RBnode* S = P->child[1-dir];
  RBnode* C;
  assert(S != NIL); // pointer to true node required
  C = S->child[dir];
  P->child[1-dir] = C; if (C != NIL) C->parent = P;
  S->child[  dir] = P; P->parent = S;
  S->parent = G;
  if (G != NULL)
    G->child[ P == G->right ? RIGHT : LEFT ] = S;
  else
    T->root = S;
  return S; // new root of subtree
}

#define RotateDir(N,dir) RotateDirRoot(T,N,dir)
#define RotateLeft(N)    RotateDirRoot(T,N,LEFT)
#define RotateRight(N)   RotateDirRoot(T,N,RIGHT)

void RBinsert1(
  RBtree* T,         // -> red–black tree
  struct RBnode* N,  // -> node to be inserted
  struct RBnode* P,  // -> parent node of N ( may be NULL )
  byte dir)          // side ( LEFT or RIGHT ) of P where to insert N
{
  struct RBnode* G;  // -> parent node of P
  struct RBnode* U;  // -> uncle of N

  N->color = RED;
  N->left  = NIL;
  N->right = NIL;
  N->parent = P;
  if (P == NULL) {   // There is no parent
    T->root = N;     // N is the new root of the tree T.
    return; // insertion complete
  }
  P->child[dir] = N; // insert N as dir-child of P
  // start of the (do while)-loop:
  do {

Notes to the insert diagrams

before

case →

rota- tion

assig- nment

after

→ next

Δh

P

G

U

x

P

G

U

x

—

I3

→

I1

→

—

I4

→

I2

N:=G

?

?

2

i

I5

P↶N

N:=P

o

I6

0

o

I6

P↷G

→

Insertion: This synopsis shows in its before columns, that all                 possible cases[32] of constellations are covered.

• In the diagrams, P is used for N’s parent, G for the grandparent, and U will denote N’s uncle.
• The diagrams show the parent node P as the left child of its parent G even though it is possible for P to be on either side. The sample code covers both possibilities by means of the side variable dir.
• N is the insertion node, but as the operation proceeds also other nodes may become current (see case I2).
• The diagrams show the cases where P is red as well, the red-violation.
• The column x indicates the change in child direction, i.e. o (for "outer") means that P and N are both left or both right children, whereas i (for "inner") means that the child direction changes from P’s to N’s.
• The column group before defines the case, whose name is given in the column case. Thereby possible values in cells left empty are ignored. So in case I2 the sample code covers both possibilities of child directions of N, although the corresponding diagram shows only one.
• The rows in the synopsis are ordered such that the coverage of all possible RB cases is easily comprehensible.
• The column rotation indicates whether a rotation contributes to the rebalancing.
• The column assignment shows an assignment of N before entering a subsequent step. This possibly induces a reassignment of the other nodes P, G, U as well.
• If something has been changed by the case, this is shown in the column group after.
• An arrow → in column next signifies that the rebalancing is complete with this step. If the column after determines exactly one case, this case is given as the subsequent one, otherwise there are question marks.
• The loop is contained in the sections "Insert case 1" and "Insert case 2", where in case I2 the problem of rebalancing is escalated ${\displaystyle \Delta h=2}$ levels higher in the tree, in that the grandfather G becomes the new current node N. So it takes maximally ${\displaystyle {\tfrac {h}{2}}}$ iterations to repair the tree (where ${\displaystyle h}$ is the height of the tree). Because the probability of escalation decreases exponentially with each iteration the total rebalancing cost is constant on average, indeed amortized constant.
• From the body of the loop, case I1 exits by itself and there are exiting branches to cases I4, I6, I5 + I6, and I3.
• Rotations occur in cases I6 and I5 + I6 – outside the loop. Therefore, at most two rotations occur in total.

Insert case 1

The current node’s parent P is black, so requirement 3 holds. Requirement 4 holds as well according to the loop invariant.

    if (P->color == BLACK) {
      // Case_I1 (P black):
      return; // insertion complete
    }
    // From now on P is red.
    if ((G = P->parent) == NULL) 
      goto Case_I4; // P red and root
    // else: P red and G!=NULL.
    dir = childDir(P); // the side of parent G on which node P is located
    U = G->child[1-dir]; // uncle
    if (U == NIL || U->color == BLACK) // considered black
      goto Case_I56; // P red && U black

first iteration

higher iteration

Insert case 2

    // Case_I2 (P+U red):
    P->color = BLACK;
    U->color = BLACK;
    G->color = RED;
    N = G; // new current node
    // iterate 1 black level higher
    //   (= 2 tree levels)
  } while ((P = N->parent) != NULL);
  // end of the (do while)-loop

  // Leaving the (do while)-loop (after having fallen through from Case_I2).
  // Case_I3: N is the root and red.
  return; // insertion complete

Insert case 4

The parent P is red and the root. Because N is also red, requirement 3 is violated. But after switching P’s color the tree is in RB-shape. The black height of the tree increases by 1.

Case_I4: // P is the root and red:
  P->color = BLACK;
  return; // insertion complete

first iteration

higher iteration

Insert case 5

Insert case 5

The parent P is red but the uncle U is black. The ultimate goal is to rotate the parent node P to the grandparent position, but this will not work if N is an "inner" grandchild of G (i.e., if N is the left child of the right child of G or the right child of the left child of G). A dir-rotation at P switches the roles of the current node N and its parent P. The rotation adds paths through N (those in the subtree labeled 2, see diagram) and removes paths through P (those in the subtree labeled 4). But both P and N are red, so requirement 4 is preserved. Requirement 3 is restored in case 6.

Case_I56: // P red && U black:
  if (N == P->child[1-dir])
  { // Case_I5 (P red && U black && N inner grandchild of G):
    RotateDir(P,dir); // P is never the root
    N = P; // new current node
    P = G->child[dir]; // new parent of N
    // fall through to Case_I6
  }

first iteration

higher iteration

Insert case 6

  // Case_I6 (P red && U black && N outer grandchild of G):
  RotateDirRoot(T,G,1-dir); // G may be the root
  P->color = BLACK;
  G->color = RED;
  return; // insertion complete
} // end of RBinsert1

void RBdelete2(
  RBtree* T,         // -> red–black tree
  struct RBnode* N)  // -> node to be deleted
 {
  struct RBnode* P = N->parent;  // -> parent node of N
  byte dir;          // side of P on which N is located (∈ { LEFT, RIGHT })
  struct RBnode* S;  // -> sibling of N
  struct RBnode* C;  // -> close   nephew
  struct RBnode* D;  // -> distant nephew

  // P != NULL, since N is not the root.
  dir = childDir(N); // side of parent P on which the node N is located
  // Replace N at its parent P by NIL:
  P->child[dir] = NIL;
  goto Start_D;      // jump into the loop

  // start of the (do while)-loop:
  do {
    dir = childDir(N);   // side of parent P on which node N is located
Start_D:
    S = P->child[1-dir]; // sibling of N (has black height >= 1)
    D = S->child[1-dir]; // distant nephew
    C = S->child[  dir]; // close   nephew
    if (S->color == RED)
      goto Case_D3;                  // S red ===> P+C+D black
    // S is black:
    if (D != NIL && D->color == RED) // not considered black
      goto Case_D6;                  // D red && S black
    if (C != NIL && C->color == RED) // not considered black
      goto Case_D5;                  // C red && S+D black
    // Here both nephews are == NIL (first iteration) or black (later).
    if (P->color == RED)
      goto Case_D4;                  // P red && C+S+D black

Notes to the delete diagrams

before

case →

rota- tion

assig- nment

after

→ next

Δh

P

C

S

D

P

C

S

D

—

D2

→

D3

P↶S

N:=N

?

?

?

0

D1

N:=P

?

?

1

D4

→

D5

C↷S

N:=N

D6

0

D6

P↶S

→

Deletion: This synopsis shows in its before columns, that all                 possible cases[32] of color constellations are covered.

• In the diagrams below, P is used for N’s parent, S for the sibling of N, C (meaning close nephew) for S’s child in the same direction as N, and D (meaning distant nephew) for S’s other child (S cannot be a NIL node in the first iteration, because it has to have black height one, which was the black height of N before its deletion, but C and D may be NIL nodes).
• The diagrams show the current node N as the left child of its parent P even though it is possible for N to be on either side. The code samples cover both possibilities by means of the side variable dir.
• At the beginning (in the first iteration) of removal, N is the NIL node replacing the node to be deleted. Because its location in parent’s node is the only thing of importance, it is symbolised by (meaning: the current node N is a NIL node and left child) in the left column of the delete diagrams. As the operation proceeds also proper nodes (of black height ≥ 1) may become current (see e.g. case D1).
• By counting the black bullets ( and ) in a delete diagram it can be observed that the paths through N have one bullet less than the other paths. This means a black-violation at P—if it exists.
• The color constellation in column group before defines the case, whose name is given in the column case. Thereby possible values in cells left empty are ignored.
• The rows in the synopsis are ordered such that the coverage of all possible RB cases is easily comprehensible.
• The column rotation indicates whether a rotation contributes to the rebalancing.
• The column assignment shows an assignment of N before entering a subsequent step. This possibly induces a reassignment of the other nodes P, C, S, D as well.
• If something has been changed by the case, this is shown in the column group after.
• An arrow → in column next signifies that the rebalancing is complete with this step. If the column after determines exactly one case, this case is given as the subsequent one, otherwise there are question marks.
• The loop is contained in the sections from Start_D through "Delete case 1", where the problem of rebalancing is escalated ${\displaystyle \Delta h=1}$ level higher in the tree in that the parent P becomes the new current node N. So it takes maximally ${\displaystyle h}$ iterations to repair the tree (where ${\displaystyle h}$ is the height of the tree). Because the probability of escalation decreases exponentially with each iteration the total rebalancing cost is constant on average, indeed amortized constant. (Just as an aside: Mehlhorn & Sanders point out: "AVL trees do not support constant amortized update costs."[17]^{: 165, 158} This is true for the rebalancing after a deletion, but not AVL insertion.[33])
• Out of the body of the loop there are exiting branches to the cases D3, D6, D5 + D6, D4, and D2; section "Delete case 3" of its own has three different exiting branches to the cases D6, D5 and D4.
• Rotations occur in cases D6 and D5 + D6 and D3 + D5 + D6 – all outside the loop. Therefore, at most three rotations occur in total.

→ Explanation of symbols

first iteration

higher iteration

Delete case 1

    // Case_D1 (P+C+S+D black):
    S->color = RED;
    N = P; // new current node (maybe the root)
    // iterate 1 black level
    //   (= 1 tree level) higher
  } while ((P = N->parent) != NULL);
  // end of the (do while)-loop

Delete case 2

The current node N is the new root. One black node has been removed from every path, so the RB-properties are preserved. The black height of the tree decreases by 1.

  // Case_D2 (P == NULL):
  return; // deletion complete

first iteration

higher iteration

Delete case 3

Delete case 3

The sibling S is red, so P and the nephews C and D have to be black. A dir-rotation at P turns S into N’s grandparent. Then after reversing the colors of P and S, the path through N is still short one black node. But N has a red parent P and a black sibling S, so the transformations in cases D4, D5, or D6 are able to restore the RB-shape.

Case_D3: // S red && P+C+D black:
  RotateDirRoot(T,P,dir); // P may be the root
  P->color = RED;
  S->color = BLACK;
  S = C; // != NIL
  // now: P red && S black
  D = S->child[1-dir]; // distant nephew
  if (D != NIL && D->color == RED)
    goto Case_D6;      // D red && S black
  C = S->child[  dir]; // close   nephew
  if (C != NIL && C->color == RED)
    goto Case_D5;      // C red && S+D black
  // Otherwise C+D considered black.
  // fall through to Case_D4

first iteration

higher iteration

Delete case 4

Delete case 4

The sibling S and S’s children are black, but P is red. Exchanging the colors of S and P does not affect the number of black nodes on paths going through S, but it does add one to the number of black nodes on paths going through N, making up for the deleted black node on those paths.

Case_D4: // P red && S+C+D black:
  S->color = RED;
  P->color = BLACK;
  return; // deletion complete

first iteration

higher iteration

Delete case 5

Delete case 5

The sibling S is black, S’s close child C is red, and S’s distant child D is black. After a (1-dir)-rotation at S the nephew C becomes S’s parent and N’s new sibling. The colors of S and C are exchanged. All paths still have the same number of black nodes, but now N has a black sibling whose distant child is red, so the constellation is fit for case D6. Neither N nor its parent P are affected by this transformation, and P may be red or black ( in the diagram).

Case_D5: // C red && S+D black:
  RotateDir(S,1-dir); // S is never the root
  S->color = RED;
  C->color = BLACK;
  D = S;
  S = C;
  // now: D red && S black
  // fall through to Case_D6

first iteration

higher iteration

Delete case 6

Case_D6: // D red && S black:
  RotateDirRoot(T,P,dir); // P may be the root
  S->color = P->color;
  P->color = BLACK;
  D->color = BLACK;
  return; // deletion complete
} // end of RBdelete2

Figure 4: Red–black trees RB_h of heights h=1,2,3,4,5,
each with minimal number 1,2,4,6 resp. 10 of nodes.

For ${\displaystyle h\in \mathbb {N} }$ there is a red–black tree of height ${\displaystyle h}$ with

${\displaystyle {\begin{array}{ll}m_{h}&=2^{\lfloor (h+1)/2\rfloor }+2^{\lfloor h/2\rfloor }-2\\&{={\begin{cases}2\cdot 2^{\tfrac {h}{2}}-2=2^{{\tfrac {h}{2}}+1}-2\\3\cdot 2^{\tfrac {h-1}{2}}-2\end{cases}}}\end{array}}}$	(with floor function ${\displaystyle \lfloor \,\rfloor }$)
	if ${\displaystyle h}$ even
	if ${\displaystyle h}$ odd

nodes and there is no red–black tree of this tree height with fewer nodes—therefore it is minimal.
Its black height is   ${\displaystyle \lceil h/2\rceil }$   (with black root) or for odd ${\displaystyle h}$ (then with a red root) also   ${\displaystyle (h-1)/2~.}$

Proof

For a red–black tree of a certain height to have minimal number of nodes, it has to have exactly one longest path with maximal number of red nodes, in order to achieve a maximal tree height with a minimal black height. Besides this path all other nodes have to be black.[16]^{: 444 Proof sketch} If a node is taken off this tree it either loses height or some RB property.

The RB tree of height ${\displaystyle h=1}$ with red root is minimal. This is in agreement with

${\displaystyle m_{1}=2^{\lfloor (1+1)/2\rfloor }\!+\!2^{\lfloor 1/2\rfloor }\!\!-\!\!2=2^{1}\!+\!2^{0}\!\!-\!\!2=1~.}$

A minimal RB tree (RB_h in figure 4) of height ${\displaystyle h>1}$ has a root whose two child subtrees are of different height. The higher child subtree is also a minimal RB tree, RB_h–1, containing also a longest path that defines its height ${\displaystyle h\!\!-\!\!1}$; it has ${\displaystyle m_{h-1}}$ nodes and the black height ${\displaystyle \lfloor (h\!\!-\!\!1)/2\rfloor =:s.}$ The other subtree is a perfect binary tree of (black) height ${\displaystyle s}$ having ${\displaystyle 2^{s}\!\!-\!\!1=2^{\lfloor (h-1)/2\rfloor }\!\!-\!\!1}$ black nodes—and no red node. Then the number of nodes is by induction

	${\displaystyle m_{h}}$	${\displaystyle =}$	${\displaystyle (m_{h-1})}$	${\displaystyle +}$	${\displaystyle (1)}$	${\displaystyle +}$	${\displaystyle (2^{\lfloor (h-1)/2\rfloor }-1)}$
			(higher subtree)		(root)		(second subtree)
resulting in
	${\displaystyle m_{h}}$	${\displaystyle =}$	${\displaystyle (2^{\lfloor h/2\rfloor }+2^{\lfloor (h-1)/2\rfloor }-2)}$	${\displaystyle +}$	${\displaystyle 2^{\lfloor (h-1)/2\rfloor }}$
		${\displaystyle =}$	${\displaystyle 2^{\lfloor h/2\rfloor }+2^{\lfloor (h+1)/2\rfloor }-2}$  ■

The graph of the function ${\displaystyle m_{h}}$ is convex and piecewise linear with breakpoints at ${\displaystyle (h=2k\;|\;m_{2k}=2\cdot 2^{k}\!-\!2)}$ where ${\displaystyle k\in \mathbb {N} .}$ The function has been tabulated as ${\displaystyle m_{h}=}$ A027383(h–1) for ${\displaystyle h\geq 1}$ (sequence A027383 in the OEIS).

Solving the function for ${\displaystyle h}$

The inequality ${\displaystyle 9>8=2^{3}}$ leads to ${\displaystyle 3>2^{3/2}}$, which for odd ${\displaystyle h}$ leads to

${\displaystyle m_{h}=3\cdot 2^{(h-1)/2}-2={\bigl (}3\cdot 2^{-3/2}{\bigr )}\cdot 2^{(h+2)/2}-2>2\cdot 2^{h/2}-2}$.

So in the even as well as the odd case, ${\displaystyle h}$ is in the interval

	${\displaystyle \log _{2}(n+1)}$	${\displaystyle \leq h\leq }$	${\displaystyle 2\log _{2}(n+2)-2=2\log _{2}(n/2+1)}$	${\displaystyle {\bigl [}<2\log _{2}(n+1)\;{\bigr ]}}$
	(perfect binary tree)		(minimal red–black tree)

with ${\displaystyle n}$ being the number of nodes.[34]

Conclusion

A red–black tree with ${\displaystyle n}$ nodes (keys) has tree height ${\displaystyle h\in O(\log n).}$

In addition to the single-element insert, delete and lookup operations, several set operations have been defined on red–black trees: union, intersection and set difference. Then fast bulk operations on insertions or deletions can be implemented based on these set functions. These set operations rely on two helper operations, Split and Join. With the new operations, the implementation of red–black trees can be more efficient and highly-parallelizable.[35] In order to achieve its time complexities this implementation requires that the root is allowed to be either red or black, and that every node stores its own black height.

• Join: The function Join is on two red–black trees t₁ and t₂ and a key k, where t₁ < k < t₂, i.e. all keys in t₁ are less than k, and all keys in t₂ are greater than k. It returns a tree containing all elements in t₁, t₂ as well as k.

If the two trees have the same black height, Join simply creates a new node with left subtree t₁, root k and right subtree t₂. If both t₁ and t₂ have black root, set k to be red. Otherwise k is set black.

If the black heights are unequal, suppose that t₁ has larger black height than t₂ (the other case is symmetric). Join follows the right spine of t₁ until a black node c, which is balanced with t₂. At this point a new node with left child c, root k (set to be red) and right child t₂ is created to replace c. The new node may invalidate the red–black invariant because at most three red nodes can appear in a row. This can be fixed with a double rotation. If double red issue propagates to the root, the root is then set to be black, restoring the properties. The cost of this function is the difference of the black heights between the two input trees.

• Split: To split a red–black tree into two smaller trees, those smaller than key x, and those larger than key x, first draw a path from the root by inserting x into the red–black tree. After this insertion, all values less than x will be found on the left of the path, and all values greater than x will be found on the right. By applying Join, all the subtrees on the left side are merged bottom-up using keys on the path as intermediate nodes from bottom to top to form the left tree, and the right part is symmetric.

For some applications, Split also returns a boolean value denoting if x appears in the tree. The cost of Split is ${\displaystyle O(\log n),}$ order of the height of the tree. This algorithm actually has nothing to do with any special properties of a red–black tree, and may be used on any tree with a join operation, such as an AVL tree.

The join algorithm is as follows:

function joinRightRB(TL, k, TR):
    if (TL.color=black) and (TL.blackHeight=TR.blackHeight):
        return Node(TL,⟨k,red⟩,TR)
    T'=Node(TL.left,⟨TL.key,TL.color⟩,joinRightRB(TL.right,k,TR))
    if (TL.color=black) and (T'.right.color=T'.right.right.color=red):
        T'.right.right.color=black;
        return rotateLeft(T')
    return T' /* T''[recte T'] */

function joinLeftRB(TL, k, TR):
  /* symmetric to joinRightRB */

function join(TL, k, TR):
    if TL.blackHeight>TR.blackHeight:
        T'=joinRightRB(TL,k,TR)
        if (T'.color=red) and (T'.right.color=red):
            T'.color=black
        return T'
    if TR.blackHeight>TL.blackHeight:
        /* symmetric */
    if (TL.color=black) and (TR.color=black):
        return Node(TL,⟨k,red⟩,TR)
    return Node(TL,⟨k,black⟩,TR)

The split algorithm is as follows:

function split(T, k):
    if (T = nil) return (nil, false, nil)
    if (k = T.key) return (T.left, true, T.right)
    if (k < T.key):
        (L',b,R') = split(T.left, k)
        return (L',b,join(R',T.key,T.right))
    (L',b,R') = split(T.right, k)
    return (join(T.left,T.key,L'),b,T.right)

The union of two red–black trees t₁ and t₂ representing sets A and B, is a red–black tree t that represents A ∪ B. The following recursive function computes this union:

function union(t1, t2):
    if t1 = nil return t2
    if t2 = nil return t1
    (L1,b,R1)=split(t1,t2.key)
    proc1=start:
        TL=union(L1,t2.left)
    proc2=start:
        TR=union(R1,t2.right)
    wait all proc1,proc2
    return join(TL, t2.key, TR)

Here, split is presumed to return two trees: one holding the keys less its input key, one holding the greater keys. (The algorithm is non-destructive, but an in-place destructive version exists as well.)

The algorithm for intersection or difference is similar, but requires the Join2 helper routine that is the same as Join but without the middle key. Based on the new functions for union, intersection or difference, either one key or multiple keys can be inserted to or deleted from the red–black tree. Since Split calls Join but does not deal with the balancing criteria of red–black trees directly, such an implementation is usually called the "join-based" implementation.

The complexity of each of union, intersection and difference is ${\displaystyle O\left(m\log \left({n \over m}+1\right)\right)}$ for two red–black trees of sizes ${\displaystyle m}$ and ${\displaystyle n(\geq m)}$. This complexity is optimal in terms of the number of comparisons. More importantly, since the recursive calls to union, intersection or difference are independent of each other, they can be executed in parallel with a parallel depth ${\displaystyle O(\log m\log n)}$.[35] When ${\displaystyle m=1}$, the join-based implementation has the same computational directed acyclic graph (DAG) as single-element insertion and deletion if the root of the larger tree is used to split the smaller tree.

Parallel algorithms for constructing red–black trees from sorted lists of items can run in constant time or ${\displaystyle O(\log \log n)}$ time, depending on the computer model, if the number of processors available is asymptotically proportional to the number ${\displaystyle n}$ of items where ${\displaystyle n\to \infty }$. Fast search, insertion, and deletion parallel algorithms are also known.[36]

The join-based algorithms for red–black trees are parallel for bulk operations, including union, intersection, construction, filter, map-reduce, and so on.

bulkInsert(T, I, k):
    I.sort()
    bulklInsertRec(T, I, k)

bulkInsertRec(T, I, k):
    if k = 1:
        forall e in I: T.insert(e)
    else
        m := ⌊size(I) / 2⌋
        (T1, _, T2) := split(T, I[m])
        bulkInsertRec(T1, I[0 .. m], ⌈k / 2⌉)
            || bulkInsertRec(T2, I[m + 1 .. size(I) - 1], ⌊k / 2⌋)
        T ← join2(T1, T2)

Execution time

Sorting ${\displaystyle I}$ is not considered in this analysis.

#recursion levels	${\displaystyle \in O(\log k)}$
T(split) + T(join)	${\displaystyle \in O(\log |T|)}$
insertions per thread	${\displaystyle \in O\left({\frac {|I|}{k}}\right)}$
T(insert)	${\displaystyle \in O(\log |T|)}$
T(bulkInsert) with ${\displaystyle k}$ = #processors	${\displaystyle \in O\left(\log k\log |T|+{\frac {|I|}{k}}\log |T|\right)}$

This can be improved by using parallel algorithms for splitting and joining. In this case the execution time is ${\displaystyle \in O\left(\log |T|+{\frac {|I|}{k}}\log |T|\right)}$.[38]

Work

#splits, #joins	${\displaystyle \in O(k)}$
W(split) + W(join)	${\displaystyle \in O(\log |T|)}$
#insertions	${\displaystyle \in O(|I|)}$
W(insert)	${\displaystyle \in O(\log |T|)}$
W(bulkInsert)	${\displaystyle \in O(k\log |T|+|I|\log |T|)}$

Execution time

Sorting ${\displaystyle I}$ is not considered in this analysis. Also, ${\displaystyle |I|}$ is assumed to be smaller than ${\displaystyle |T|}$, otherwise it would be more efficient to construct the resulting tree from scratch.

T(find insert position)	${\displaystyle \in O(\log |T|)}$
#stages	${\displaystyle \in O(\log |I|)}$
T(insert) + T(repair)	${\displaystyle \in O(\log |T|)}$
T(bulkInsert) with ${\displaystyle |I|}$ ~ #processors	${\displaystyle \in O(\log |I|+2\cdot \log |T|)}$ ${\displaystyle =O(\log |T|)}$

Work

W(find insert positions)	${\displaystyle \in O(|I|\log |T|)}$
#insertions, #repairs	${\displaystyle \in O(|I|)}$
W(insert) + W(repair)	${\displaystyle \in O(\log |T|)}$
W(bulkInsert)	${\displaystyle \in O(2\cdot |I|\log |T|)}$ ${\displaystyle =O(|I|\log |T|)}$

A red–black tree was referenced correctly in an episode of Missing[40] as noted by Robert Sedgewick in one of his lectures:[41]

Jess: It was the red door again.
Pollock: I thought the red door was the storage container.
Jess: But it wasn’t red anymore, it was black.
Antonio: So red turning to black means what?
Pollock: Budget deficits, red ink, black ink.
Antonio: It could be from a binary search tree. The red–black tree tracks every simple path from a node to a descendant leaf that has the same number of black nodes.
Jess: Does that help you with the ladies?

• List of data structures
• Tree data structure
• Tree rotation
• AA tree, a variation of the red–black tree
• AVL tree
• B-tree (2–3 tree, 2–3–4 tree, B+ tree, B*-tree, UB-tree)
• Scapegoat tree
• Splay tree
• T-tree
• WAVL tree

• Mathworld: Red–Black Tree
• San Diego State University: CS 660: Red–Black tree notes, by Roger Whitney
• Pfaff, Ben (June 2004). "Performance Analysis of BSTs in System Software" (PDF). Stanford University.

• Ben Pfaff: An Introduction to Binary Search Trees and Balanced Trees. Free Software Foundation, Boston 2004, ftp.gnu.org (PDF gzip; 1662 kB)
• A complete and working implementation in C
• OCW MIT Lecture on Red-black Trees by Erik Demaine
• Binary Search Tree Insertion Visualization on YouTube – Visualization of random and pre-sorted data insertions, in elementary binary search trees, and left-leaning red–black trees
• An intrusive red–black tree written in C++
• Red–black BSTs in 3.3 Balanced Search Trees
• Red–black BST Demo