(1) ST: the splay tree that provides insertion and lookup of the desired key; (2) Count: a counter that records of the number of nodes in ST; (3) S: the node that has the minimum ID value in ST; (4) T: the node that has the maximum ID value in ST.
As with caching, when a lookup is performed on node n, n firstly searches its splay tree in SFT for the desired key.
Each node maintains a SFT which contains a splay tree. When a node n is created, it sets up an initial splay tree for its SFT by initiating lookup RPCs to find m successors, that is, successor (n * id + [2.sup.i]), 0 [less than or equal to] i [less than or equal to] m - 1.
The fingers are then inserted to the splay tree using the splay tree insertion operation.
Figures 2 and 3 compare the calendar queue hold time to the hold time for splay tree and linear linked list priority queue implementations.
Figure 2 shows that on the Harris minicomputer the calendar queue hold time becomes smaller than the splay tree hold time when the queue size reaches 20, and stays smaller as the queue grows.
Binomial queues, pagodas, skew heaps, pairing heaps, and splay trees run with O(log n) time per hold operation.
The splay tree, a self-adjusting form of binary search tree that Danny Sleator and I developed, is one such data structure.
In a splay tree, each retrieval of an item is followed by a restructuring of the tree, called a splay operation.
As Figure 7 suggests, a sequence of costly retrievals in an originally very unbalanced splay tree will quickly drive it into a reasonably balanced state.
Splay trees [2, 3] are an excellent candidate for use in this context.
Lacking this, an empirical test of my hypothesis about the relative performance of splay trees and min-max heaps must rest on their use in particular applications.