Self-adjusting trees in practice for large text collections Hugh E. Williams Justin Zobel Steffen Heinz Department of Computer Science, RMIT University GPO Box 2476V, Melbourne 3001, Australia. E-mail: hugh,jz,sheinz @cs.rmit.edu.au { } June 18, 2002 Abstract Splay and randomised search trees are self-balancing binary tree structures with little or no space overhead compared to a standard binary search tree. Both trees are intended for use in applications where node accesses are skewed, for example in gathering the distinct words in a large text collection for index construction. We investigate the efficiency of these trees for such vocabulary accumulation. Surprisingly, unmodified splaying and randomised search trees are on average around 25% slower than using a standard binary tree. We investigate heuristics to limit splay tree reorganisation costs and show their effectiveness in practice. In particular, a periodic rotation scheme improves the speed of splaying by 27%, while other proposed heuristics are less effective. We also report the performance of efficient bit-wise hashing and red-black trees for comparison. 1INTRODUCTION A key task in constructing an index for a large text collection is gathering the distinct words in the collection. In this paper we investigate the use of the splay and randomised search trees— two well-known self-adjusting binary search trees—for managing a large lexicon of words of this kind. Sleator and Tarjan [20], in their original description of the splay tree, propose heuristics for reducing the costs of self-adjustment and note “that the practical efficiency of various splaying and [heuristic] semisplaying methods remains to be determined”. One motivation for our work is to augment theoretical analyses [1] by experimenting with efficiency heuristics for index construction in large text databases. In addition, we seek to verify whether it is true that “splay trees are as efficient as balanced trees when total running time is the measure of interest” and whether, as claimed, “they can be much more efficient if the usage pattern is skewed” [20]. Splay and randomised search trees can be used for fast searching and insertion in index con- struction for large text databases. In this task, a sequence of word occurrences is extracted from the text to be indexed. The number of word occurrences greatly exceeds the number of distinct words, but new words continue to be seen—at a rate of perhaps one in a thousand oc- currences [25]—even after many gigabytes of text have been processed. The distribution of words is highly skew: in typical English text around one word in twelve is “the”, and around one word occurrence in five is one of “the”, “and”, “or”, “of”, or “a”. In a large text collection, the majority of distinct words (which are typically typographic errors, nonsense strings, or unusual strings such as chemical names or fragments of genomes) occur once only. Each word occurrence in the collection is searched for in the tree structure. If the word is new, a node is added to the tree to contain it; otherwise the information about the word is updated (since the purpose of gathering distinct words is to collect statistics about them). In a standard splay tree, a new or accessed node is then splayed to the root of the tree. In a randomised search tree, a node may be rotated towards the root one or more times; this depends on a randomly-generated priority associated with the node, and the relative priority of nodes above the new node. 1 Index construction might be considered an ideal application of these trees, since the amortised time cost over the data set is important, not the cost of an individual search or insertion. Amortised structures are designed to be usually not much worse than the average performance of a more rigid structure and, in applications where the the access patterns are not uniform, they are potentially more efficient. Indeed, efficient search systems, such as the mg text database [24] and the cafe indexed genomic search system [22], use splay trees for index construction. The splay tree is also memory-efficient compared to other structures that might be used for index construction. Other structures—such as the B-tree [3, 20]—have significantly more internal structures to maintain rigid balance. The randomised search tree is less memory efficient as a priority value is stored in each node. However, heuristic approaches that do not store priorities have been proposed. We report experiments in this paper with unmodified top-down splaying, existing and novel bottom-up heuristic splaying, randomised search trees, and compare these to an unbalanced binary tree, a red-black tree, and hashing as a method for creating and storing large lexicons. (We use BST to denote a standard, unbalanced binary search tree throughout this paper.) We have found that unmodified splaying and randomised search trees are typically slower than using a BST and, moreover, randomised search trees in particular are less space-efficient. These results are despite the strongly skewed distribution of words. Moreover, we have found that heuristics proposed by Sleator and Tarjan [20] typically do not work better than an unmodified splay tree. However, a simple, novel periodic rotation heuristic works well, reducing the vocabulary accumulation time on a large collection by around 27% over an unmodified splay tree. While this heuristic means that the worst case of the modified splay tree is little better than that of a BST, the worst case is much less likely to arise and we do not believe that it would be a significant problem in practice. We have compared our heuristic splay tree to hashing with a fast, uniform hash function [16]. The hash table is more than 18% faster than the splay tree for inserting data. However, in some cases, trees may be preferred to hash tables for managing collections of words. 2 SPLAY TREES Splay trees are binary search trees that are incrementally reorganised to avoid the worst-case linear search and insertion time of a BST [20]. The storage costs of a standard splay tree are the same as BSTs; no counters, pointers, or balance information need be stored. Splay trees do not require that a tree be balanced, but rather that each access reorganises the tree to make the tree, on average, more balanced. This process of reorganisation, or splaying, brings each accessed node to the root of the tree, roughly halving the depth of all nodes along the access path. The rationale is that, for data with a skew distribution, some nodes will be accessed more often than others. With incremental reorganisation, such nodes will cluster towards the root of the tree, reducing the traversal costs of searching the tree for common nodes; this is a similar principle to move-to-front reorganisation of linked lists. Splaying is implemented using rotations. The majority of rotations performed are one of two kinds of double rotation,azig-zag or zig-zig. Rotations are applied to a node until it is the root of the tree. This reorganisation heuristic guarantees for m accesses that the cost of accessing a tree of n nodes is O(m log n) in time if there are at least as many accesses as there are nodes in the tree, that is, m n. However, the access time for a single access in a splay tree may be O(n)in time. Thus splay≥ trees are an amortised structure: the overall cost of accessing nodes is reduced, but not necessarily the cost of accessing an individual node. Rotation works as follows. A zig-zag rotation is used to move a node two levels towards the root in two cases: when a node is the left child of its parent, and its parent is the right child of its grandparent; and when a node is the right child of its parent, and its parent is the left child of its grandparent. An example of zig-zag rotation is shown in Figure 1, where a node C with a parent P and a grandparent G are zig-zagged. A zig-zig rotation is used in the other two possible grandparent, parent, and child arrangements: where a node is the left child of its parent, and the parent is the left child of the grandparent; 2 G Z Z C Z ""b P Z " b ¤D " bb ,l P G , l ¤ D , ¤ D C 4 \ \ ¤D ¤ D \ \ ¤ D \ \ \ \ ¤D ¤D ¤D ¤D ¤1D \ ¤ D ¤ D ¤ D ¤ D ¤ D ¤D ¤D ¤1D ¤ 2D ¤3 D ¤ 4D ¤ D ¤ D ¤ D ¤ D ¤ D ¤ D ¤ 2D ¤3D ¤ D ¤ D Figure 1: Zig-zag rotation. G C Z Z Z ZZ P ZZ P ¤D ¤D ,,l ,l , l ¤ D ¤ D , l C l ¤ 4D ¤1D , G ¤D ¤ D ¤ D ¤D \ ¤ D ¤ D \ \\ ¤3 D ¤2 D \\ ¤D ¤D ¤ D ¤ D ¤D ¤D ¤ D ¤ D ¤ D ¤ D ¤1 D ¤ 2D ¤ 3D ¤4 D ¤ D ¤ D ¤ D ¤ D Figure 2: Zig-zig rotation. 3 P C ,,l ,l , l , l C l , P ¤D ¤D \ ¤ D ¤ D \ \\ ¤3D ¤1 D \\ ¤D ¤D ¤ D ¤ D ¤D ¤D ¤ D ¤ D ¤ D ¤ D ¤1D ¤2 D ¤2D ¤ 3D ¤ D ¤ D ¤ D ¤ D Figure 3: Single rotation. and where a node is right child of the parent, and the parent is the right child of the grandparent. An example of zig-zig rotation is shown in Figure 2, where a node C with a parent P and a grandparent G are zig-zigged. The final class of rotation is where there is no grandparent, that is, where the node to be rotated is the child of the root.