One drawback of the suffix tree is that it demands much more memory than the text it represents and the same applies to its construction. Its time complexity can quickly become unmanageable.

For an online CS course I was asked to build a suffix tree. The algorithm I initially submitted did not meet the assessment system’s requirements in terms of speed and memory usage and, as a result, I had to start all over.

As it turned out, when building a suffix tree, one must use memory and processing power as efficiently as possible.

What I will show here is a strategy to do exactly that, with a smarter but still relatively simple algorithm that nevertheless offers significant gains in speed and memory usage compared to the naive method. This is not Ukkonen's algorithm, because it still operates in O(n²) time, but for its class it still is quite fast.

Creating a suffix tree in three stages

Let's start with a description of the algorithm I initially built, as it perfectly and clearly illustrates what needs to be done. It follows a commonly used and logical approach.

We start with a suffix trie. A trie is a specialized tree for storing single characters. Gradually the suffix trie is compressed into a suffix tree.

The tree and trie (from retrieval) datastructures start with a single root node, which more or less corresponds to the trunk of a real tree, and which has branches with perhaps further branches and eventually leaves.

Creating a suffix tree for a text T can relatively easy be done by first building a suffix trie character by character out of all suffixes of a string, then compressing all single child nodes into multi-character nodes, and finally replacing the labels on those nodes by their coordinates in the text. This is the three-step approach.

It might not be immediately clear what this is all about, so let's look at it step by step. To start with, consider the suffixes for T = 'banana' (using $ as a unique closing character):

0 BANANA$
1  ANANA$
2   NANA$
3    ANA$
4     NA$
5      A$
6       $

There are 7 suffixes that we want to store in a tree. Let's first build the suffix trie for 'banana' by adding the characters of the suffix strings above top to bottom to a root node. When, starting from root, a character is already on the trie, do not add it, but move on to the next character and branch off as soon as you reach a character that is not yet on the branch. Doing so, we save space by reusing common parts of the strings.

As an example, adding the first three suffixes (0, 1 and 2 in the list above) results in this intermediate state of the trie:

         |---B---A---N---A---N---A---$  (0)
         |       
ROOT-----|---A---N---A---N---A---$  (1)
         |
         |---N---A---N---A---$  (2)

These first three suffixes do not share any prefix characters, so they all branch off immediately from the root. However, when inserting the fourth suffix ('ANA$') we encounter a shared prefix on the 2nd branch in the picture above. It's the first A on the 2nd branch, and the subsequent N and A are also shared.

We can reuse the first 3 characters on the 'ANANA\(' branch until we reach the second 'N'. The 'N' character obviously does not match the '\)' character in our suffix 'ANA$', so there we split the branch:

         |---B---A---N---A---N---A---$  (0)
         |       
         |               |---N---A---$  (1)
ROOT-----|---A---N---A---|
         |               |---$  (3)
         |
         |---N---A---N---A---$  (2)

Now there are four suffixes on the trie, representing 7 + 6 + 5 + 4 = 22 characters, but there are only 19 characters on the trie, so we saved 3 characters. Continuing likewise with the remaining suffixes we get the complete suffix trie for 'banana':

         |---B---A---N---A---N---A---$  (0)
         |
         |                   |---N---A---$  (1)
         |       |---N---A---|
         |       |           |---$  (3)
         |---A---|
         |       |
ROOT-----|       |---$  (5)
         |
         |           |---N---A---$  (2)
         |---N---A---|
         |           |---$  (4)
         |
         |---$  (6)

Though all the suffixes together count 28 characters, the trie contains only 22. We did save some space.

Unfortunately, for longer texts this structure still becomes rather bulky in terms of memory usage.

Can we save more space? Fortunately, it is indeed possible to save even more space by taking a few additional measures:

1. Reassemble the non-branching runs of nodes (that all carry a single character) into a single node spelling out a multi-character substring of text T;

2. replace the resulting (potentially long) multi-character strings by their position and length in text T.

Compressing the non-branching nodes into multi-character nodes (step 1) significantly reduces the number of nodes from 22 to 11. Now this is what is called a suffix tree (not trie):

         |----BANANA$  (0)
         |
         |                |---NA$  (1)
         |       |---NA---|
         |       |        |---$  (3)
         |---A---|
         |       |
ROOT-----|       |---$  (5)
         |
         |        |---NA$  (2)
         |---NA---|
         |        |---$  (4)
         |
         |---$  (6)

The amount of nodes is significantly smaller, but still the amount of characters in the tree remains the same as before and the substrings on the node labels are copied over and over.

Therefore, to further reduce memory usage we replace each label with a number pair describing the label's starting position in text T and its length (step 2):

Text:     BANANA$
Position: 0123456

         |-----(0,7)  (0)
         |
         |                   |--(4,3)  (1)
         |         |--(2,2)--|
         |         |         |--(6,1)  (3)
         |--(1,1)--|
         |         |
ROOT-----|         |--(6,1)  (5)
         |
         |         |--(4,3)  (2)
         |--(2,2)--|
         |         |--(6,1)  (4)
         |
         |--(6,1)  (6)

Now this makes a difference, since longer substrings require no more memory than the shorter ones. The tree no longer contains copied text parts; instead, it entirely consists of pointers to the text T, which is kept in memory just once.

To summarise, the above procedure for building a compressed suffix tree consists of three steps:

1. Create a suffix trie for text T;

2. compress each run of non-branching single character nodes into a single multi-character node;

3. replace the labels on the resulting multi-character nodes with their pointers in the text T.

Steps 2 and 3 can be merged into a single process, but steps 1 and 2 require separate passes. Moreover, though compressed in the end, the structure still takes up lots of memory immediately after step 1.

That begs the question: can all 3 steps be carried out in a single loop, keeping memory usage to a minimum at every stage in the process? Can we build a compressed suffix tree directly without building an intermediate suffix trie first?

Building a compressed suffix tree with a smarter algorithm

The answer is: yes, and it significantly reduces memory usage, thereby greatly speeding up the construction of the suffix tree.

However, the algorithm becomes slightly more complex compared to the three-step approach. You’ll have to trust me on that because I will skip showing the code for the three-step approach above and head over directly to the single pass algorithm.

Again we add the suffixes to the root, starting with the longest suffix and ending with the single character closing sign ('$'). This time however the nodes carry strings and not just single characters.

Let's add the first 3 suffixes to the root. Like before, each one of them branches off immediately from the root since they do not share a prefix:

         |---BANANA$  (0)
         |
ROOT-----|---ANANA$  (1)      
         |
         |---NANA$  (2)

Things change when adding the fourth suffix 'ANA\( to the tree'. Its first three characters are already on the second branch ('ANANA\)'). These two suffixes can thus share the common prefix 'ANA' and branch from where they differ:

         |---BANANA$  (0)
         |
         |         |---NA$  (1)
ROOT-----|---ANA---|
         |         |---$  (3)
         |
         |---NANA$  (2)

This time we had to split a node when branching. In the (single character) trie that would never occur. So this adds a bit of extra complexity: where and how do you split a node?

Continuing, we achieve the same tree as before, but without the compression step, since the nodes were already compressed, and split when necessary:

         |---BANANA$  (0)
         |
         |                |---NA$  (1)
         |       |---NA---|
         |       |        |---$  (3)
ROOT-----|---A---|
         |       |
         |       |---$ (5)
         |
         |
         |        |---NA$  (2)
         |---NA---|
         |        |---$  (4)
         |
         |---$  (6)

For illustration, the text representations are shown on the nodes above, but in the real algorithm, the strings are represented by their numeric pointer values right from the start. This prevents the tree from still taking up too much memory during construction.

Constructing the algorithm

Let's see if we can condense all the above thoughts into a pseudo-code algorithm and build a suffix tree in a single pass.

Pseudo code algorithm

For every suffix S of text T:

1. set the current node to the root node;

2. see if one of the node's children shares a prefix with suffix S;

3. if there is no common prefix, add a new node for suffix S to node. Stop here and move on to the next suffix;

4. but if suffix S shares a common prefix with one of the current node's children, determine whether the child node child containing the prefix must be split in two:

   1. if the entire label of the child node is the prefix, do not split it;

   2. if the label of the child node extends beyond the prefix, split the child node immediately after the prefix;

5. repeat step 2 with the current node set to the child node identified in step 4, and remove the common prefix from the beginning of the suffix. Eventually each recursion will end at step 3.

Splitting a node on a common prefix

As an aside, let's leave the suffixes for a moment and use a few common words for the sake of the example. We must distinguish two cases of commonality in prefixes:

1. Strings 'disco' and 'disciple' share prefix 'disc'. The first string shares a prefix with the second.

2. Strings 'disc' and 'disclaimer' also share prefix 'disc'. In this case however the first string is a prefix for the second.

This distinction dictates whether a node needs to be split.

Imagine a node 'DISC' is on a tree containing both 'DISCO' and 'DISCIPLE'. Adding 'DISCLAIMER' does not require splitting the 'DISC' node:

                |---O   
ROOT-----DISC---|
                |---IPLE

                ↑

                | 
                |---LAIMER

How about adding 'DISTANT'? It shares a prefix with 'DISC', but only part of it, so now we do have to split 'DISC' in two parts:

'DIS' (the prefix) and 'C' (the remainder):

                       |---O
                       |
               |---C---|---IPLE
               |       |
               |       |---LAIMER   
ROOT-----DIS---|

               ↑

               |
               |---TANT
               

The remainder 'C' keeps the 3 children of the previously undivided node, while the node itself is shortened to the common prefix 'DIS'. The remainder 'C' (including the tree below it) together with the suffix minus the common prefix ('DIS TANT') are inserted as the shortened node's new children.

Writing the algorithm

I use Scala to write the algorithm. Scala is concise and offers some expressiveness not found in Java, while still being strongly typed, which makes coding much easier in my opinion.

The Node class models a node in the tree. It has fields for children (a list), and start and length (integers), pointing to the text T which will be stored in global variable allText.

Note that contrary to the tree examples above, as said, no strings will be stored on the nodes. There will only be pointers to sections of allText. This certainly makes programming more complex, which is why, for debugging purposes, the toString function is overridden to convert the (start,length) pointers - that define the sections - back into actually readable text.

val allText = "..." 

class Node( var start: Int = 0, var length: Int = 0 ) {

  // An empty list to hold the child nodes
  var children = mutable.MutableList[Node]()

  override def toString: String =
    f"${allText.substring(start,start+length)}"
}

Building the tree consists of generating all suffixes from the text allText and adding them to the tree. We initialize the tree with an empty root node, then add the suffixes one by one.

The first suffix added is the entire text allText (including the closing character '\('), and the last suffix to be added is just the closing character '\)'.

private def buildTree(): Node = {

  /* Initialise the empty root node
  */  
  val tree = new Node()

  /* Add suffixes 
  */  
  for (i <- 0 until allText.length) 

    // [PC-1]
    addSuffixToNode(i, tree)  

  /* Return the resulting tree
  */  
  tree
}

The main procedure

The main procedure is addSuffixToNode, which updates the tree we have built so far by inserting a suffix. There are two helpers methods, commonPrefix and splitNodeOnPrefix, which will be explained later. Please follow along with the code comments to see what happens where. The [PC-X] codes refer to the pseudo algorithm shown previously.

Remember, none of these methods handles any String data. All strings are represented by their coordinates in allText.

@tailrec
private def addSuffixToNode(

  suffixStart: Int, 
  node: Node,
  searchPrefix: Boolean = true ): Unit = {

  /* 'sharedPrefix' will consist of a Node and the Int pair 
     pointing to the location of the prefix in allText
  */
  var sharedPrefix: Option[(Node, (Int, Int))] = None
  /*
     Boolean 'continue' allows us to bypass the commonPrefix
     call when we have found a common prefix or we can be sure 
     none will be found.
  */  
  var continue = searchPrefix 

  /* [PC-2]

     find a child node that shares a common prefix 
     with suffix 
  */
  if (continue) for (child <- node.children) { 

    val (prefixStart, prefixLen) = commonPrefix(
      allText, (child.start, child.length), suffixStart
    )

    if (prefixStart != -1) {

      /* There can only be one node with a matching prefix
         so look no further
      */     
      continue = false
      sharedPrefix = Some(child, (prefixStart, prefixLen))
    }
  }

  /* [PC-3]

     This suffix shares nothing with any existing children 
     of node, so insert as a new child of node and quit
  */
  if (sharedPrefix.isEmpty) {

    val newNode = new Node()
    newNode.start = suffixStart
    newNode.length = allText.length - newNode.start
    node.children += newNode
  }
  /* [PC-4]

     There is a child node sharing a common prefix 
     with the suffix
  */
  else {

    /*
      Get the child as 'node', and the length of the prefix
    */    
    val (node, (_, prefixLength)) = sharedPrefix.get

    /* [PC-4.1]

       The prefix is the entire node's value -
       no need to split
    */
    if (node.length == prefixLength)

      /* [PC-5]

         continue on the child node for the remaining
         part of the suffix
      */
      addSuffixToNode(suffixStart + prefixLength, node)

    /* [PC-4.2]

       If the node's value extends beyond the prefix,
       it must be split after the prefix
    */
    else {

      splitNodeOnPrefix(node, prefixLength)

      /* [PC-5]

         continue on the child node for the remaining
         part of the suffix - skip the commonPrefix
         call since there will be none (it would have
         led to an existing child in the current run)
      */
      addSuffixToNode(suffixStart + prefixLength, node, false)

    }
  }
}

A few remarks:

• The searchPrefix boolean method argument serves to skip the search for a common prefix further up on a branch after we have split a node. It saves a few unnecessary loops, but it's not essential for the algorithm to work correctly.

• The @tailrec annotation guarantees the compiler to optimize the recursions not to heap on the stack until a stack overflow error may occur. The @tailrec annotation only compiles if the recursive call is indeed in tail position.

Finding common prefixes

Now let's explore the commonPrefix function. It serves to find the common prefix shared by a suffix and a node, if any. It returns a (start,length) pair, referring to the position of the prefix in text T (allText), unless none is found, in which case it returns (-1,0).

Example: commonPrefix(text, (2,3), 9) 
         returns (2,3)

  ___    ___
ABCDEFGHACDEFGHABXYZAAABDRHTYEIOEOE ← text
  : :    : :
  : :    9th - 11th character 
  : :
  2nd character and infix length 3
 "CDE"
 
 (NB. infix length is 3, though the common part is longer) 

So here's the function code. It builds the common prefix string character by character, adding the part found so far to the accumulator argument result and stopping the recursion when the next character doesn't match, or when the loop goes past the infix length or the end of the text.

/* commonPrefix finds the common prefix in text 
   for node and suffix.
*/
@tailrec
private def commonPrefix(

   text: String, 
   infix: (Int, Int), 
   suffixStart: Int, 
   result: (Int,Int) = (-1,0) ): (Int,Int) = {

  val (nodeStart, nodeLength) = infix;

  /* If there are no more characters left
     or the prefix would extend beyond the start of
     the suffix, return the prefix
  */
  if (nodeLength == 0 || nodeStart == suffixStart 
      || suffixStart  >= text.length)
    
    result

  /* Otherwise if there is no common prefix (the starting 
     characters don't match), return the empty prefix (-1,0)
  */  
  else if (text(nodeStart) != text(suffixStart))

    result

  /* Otherwise keep moving, save the matching character in the
     accumulator 'result' and recursively advance to the next 
     character.
  */  
  else {

    /* Once a start value is identified, retain it — 
       it must persist through recursions.
    */
    val start = if (result._1 == -1) nodeStart else result._1  

    /* recursively move to the next character 
    */
    commonPrefix(
      text, 
      (nodeStart + 1, nodeLength - 1), 
      suffixStart + 1, 
      (start, result._2 + 1)
    )
  }
}

The above function provides a mechanism to identify a shared prefix between any two positions in text T without copying the strings, simply by comparing runs of characters starting at the specified positions in text T.

Splitting a node on a prefix

The next thing to investigate is how a node is split on a prefix. A picture is worth more than a thousand words:

Example: node = ABCDE, 3 children 

           |---child_1 
           |
  ABCDE----|---child_2
           | 
           |---child_3
      
          
Split node ABCDE on prefix AB:  

 node             |---child_1
  :               |
  AB-----CDE------|---child_2 
         :        | 
       newNode    |---child_3

Essentially, the node is divided immediately after the prefix. This results in one node containing just the prefix and having a single child node that holds the remaining characters, along with the node's children from before the split. Here's the procedure that does exactly that:

private def splitNodeOnPrefix(

  node: Node, 
  prefixLen: Int ): Node = {

  val children = node.children
  
  /* get the node's value without the prefix 
  */
  val (postfixStart, postfixLen) = 
    (node.start + prefixLen, node.length - prefixLen)
  
  /* create a new Node from the value obtained in the 
     previous step 
  */
  val newNode = new Node(postfixStart, postfixLen)

  /* add the original node's children to the new node
  */
  newNode.children ++= children
  
  /* shorten the original node to just the prefix length
  */ 
  node.length = prefixLen

  /* remove its children (they are moved to newNode)
  */
  node.children.clear()

  /* add newNode as its child
  */
  node.children += newNode

  /* return the split node */
  node
}

Nothing too complicated here. On to the final step, getting the output.

Printing the tree

We want to be able to view the resulting tree in an intelligible and verifiable way. Here's a depth-first approach to printing the resulting tree. A stack is used instead of recursion to prevent the thing from exploding and minimal formatting indents the child branches.

private def printTree(node: Node, text: String): Unit = {

  // Do not use recursion, it might blow up
  val stack = mutable.Stack[(Node, Int)]()
  stack.push((node, 0))

  while (stack.nonEmpty) {
    val (node, depth) = stack.pop()
    println(
      "    " * depth + "|---" + (
        if (node.start == 0 && node.length == 0) 
          "ROOT"
        else 
          text.substring (
            node.start, 
            Math.min(node.start + node.length, text.length)
          )
      )
    )
    node.children.foreach(c => stack.push((c,depth+1)))
  }
}

For input 'abracadabra$' the following output is returned:

abracadabra$

|---ROOT
    |---$
    |---dabra$
    |---cadabra$
    |---ra
        |---$
        |---cadabra$
    |---bra
        |---$
        |---cadabra$
    |---a
        |---$
        |---dabra$
        |---cadabra$
        |---bra
            |---$
            |---cadabra$

And this is exactly what one would expect. This is the output for a correct suffix tree, constructed without an intermediate trie and no characters are stored in the tree itself at any stage.

How does it perform?

Finally, we want to know whether it was all worth it. Is the above algorithm indeed more memory efficient and possibly faster than the three step approach with an intermediate trie?

Well, it seems it is indeed. Running a 10,000 character string from a 4 letter alphabet, using the three step algorithm, on my system takes about 25,000 milliseconds on average (based on 10 tests). The same input with the second algorithm takes about 500 milliseconds.

That's about 50 times faster. That's a minute for an hour.

Worst case performance

The O(n²) time complexity describes the worst case scenario. What is meant by 'worst case' becomes clear when we compare the performance of two large texts of very different quality that are used as input for the algorithm.

The first 'text' is a sequence of 300,000 characters, again drawn from a 4 letter alphabet (like a DNA code). Due to its limited alphabet this text contains a lot of repetitions. The second text is the complete story H.G. Wells' War of the Worlds, taken from the Gutenberg site (330,000 characters). As this text is meaningful prose there will be far fewer repetitions.

On the 4 letter alphabet text the algorithm takes around 5~6 minutes to complete. On the H.G. Wells text the algorithm completes in less than 2 seconds.

A huge difference, which can be explained by the fact that because of the many repetitions in the four-letter text, the commonPrefix function on average will take much longer to complete. For each of the n suffixes, the function, as it were, runs much deeper into the n characters of the text. For the Wells text the prefixes will be shorter, cutting of the loop earlier.

(In both cases however, the three step algorithm just chokes on it.)

Overall, that's quite impressive. As a result the smarter algorithm did pass all the tests with flying colours.

Summary

A suffix tree is a data structure that enables quick indexing and searching of large texts or strings like DNA sequences. It contains all possible text endings, facilitating rapid pattern searches. However, it requires significantly more memory than the text it represents, and its construction potentially leads to unmanageable memory and time complexity.

To optimize memory usage and processing efficiency, this article describes a simple yet smart algorithm that constructs a suffix tree in a single pass, without first having to construct an intermediate, memory-intensive trie.

Performance tests demonstrate that this optimized algorithm operates significantly faster than the approach with the intermediate trie, achieving a speed improvement of about 50 times for a 10,000 character input.