Abstract
The all-pairs suffix-prefix matching problem is a basic problem in string processing. It has an application in the de novo genome assembly task, which is one of the major bioinformatics problems. Due to the large size of the input data, it is crucial to use fast and space efficient solutions. In this paper, we present a space-economical solution to this problem using the generalized Sadakane compressed suffix tree. Furthermore, we present a parallel algorithm to provide more speed for shared memory computers. Our sequential and parallel algorithms are optimized by exploiting features of the Sadakane compressed index data structure. Experimental results show that our solution based on the Sadakane’s compressed index consumes significantly less space than the ones based on noncompressed data structures like the suffix tree and the enhanced suffix array. Our experimental results show that our parallel algorithm is efficient and scales well with increasing number of processors.
1. Introduction
Given a set of strings , the all-pairs suffix-prefix problem (APSP) is to find the longest suffix-prefix match for each ordered pair of the set . Solving this problem is a basic step in the de novo genome assembly task, where the input is a set of strings representing random fragments coming from multiple copies of the input genome. These fragments can be ordered based on suffix-prefix matching and after some postprocessing, the input genome can be reconstructed.
With the recent advances in high throughput genome sequencing technologies, the input size became very huge in terms of the number of sequences and length of fragments. This calls for both faster and memory efficient solutions for the APSP problem.
The APSP is a well-studied problem in the field of string processing. The first nonquadratic solution was introduced by Gusfield et al. [1]. Their algorithm was based on the generalized suffix tree and it takes time and linear space, where is the total length of all strings. Although the theoretical bounds of this algorithm are optimal, the cache performance and space consumption of the suffix tree are major bottlenecks to solve large size problems (note that the best implementation of a suffix tree consumes 20 bytes per input character [2]).
Ohlebusch and Gog [3] introduced a solution to APSP using the enhanced suffix array [4], which is an index data structure that uses only 8 bytes per input character. Their algorithm has the same complexity as that of [1]. Their algorithm has exploited interesting features of the enhanced suffix array, which has not only reduced the space consumption but also improved the cache performance and accordingly the running time. Experimental results have shown that their solution is 1.5 to 2 times faster in practice and can indeed handle large problem sizes.
In an effort to reduce the space consumption of solving the problem, Simpson and Durbin [5] used the FM index [6] to solve the problem in an indirect way as follows. The index is constructed for all strings after concatenating them in one string. The index is then queried by the reads, one by one, to find prefix-suffix matches. The time complexity of this algorithm is not as optimal as the one of [1, 3], because one examines more suffixes than the output size. (This limitation stems also from the fact that the FM index lacks structural information to run the algorithms of [1] or [3] on it.) But its space consumption is much less than that of the previous algorithms.
In this paper, we present new methods based on the compressed suffix tree of Sadakane [7] and variations of the algorithms of [1] and [3]. The compressed suffix tree is considered as a self-index data structure, because the original text is already encoded in the index in a compressed fashion and can be extracted from it; that is, there is no need to keep the original text in the memory. It is also fully functional like the uncompressed suffix tree, as it offers the typical suffix tree operations such as checking if a node is a leaf, moving to the next sibling, using a suffix link, or even performing lowest common ancestor queries. Such compressed suffix tree consumes much less space than the suffix tree and the enhanced suffix array but more space than the FM index [6], as it includes additional structural information.
To further speed up the solution of APSP, we introduce different parallelization strategies to the sequential algorithm that can be used on multiprocessor shared memory computers. Our parallelization methods exploit important features and available operations of the Sadakane’s compressed suffix tree. Experimental results show that our method is efficient and scales well with the number of processors.
This paper is organized as follows. In Section 2, the data structures and the functions used in our solutions are explained. In Section 4, the two different approaches for solving APSP using Sadakane index are demonstrated. Section 5 describes how our solutions can be parallelized, and finally we show our experimental results and conclusions in Sections 6 and 7, respectively.
2. Overview
2.1. Basic Notions
We write to denote a set of strings. Each string is defined over an ordered alphabet . For strings representing genomic sequences, , which is the standard alphabet for DNA sequence data. We write to denote the length of the string and to denote the th character, where . The th suffix of a string is the substring and it is denoted by . A prefix of length of a string is the substring . For two strings and , the longest suffix-prefix match of the pair is the match with the greatest such that .
The suffix tree of a string is an index structure in which each suffix of is stored as a path from the root to a leaf. Obviously many suffixes will share partial path before they end in different leaves. Accordingly, the suffix tree of a string has leaves and at most internal nodes, where . Suffix tree can be constructed and stored in linear time and space ([8, 9]).
2.2. Compressed Suffix Tree
Sadakane’s compressed suffix tree [7] is composed of three major components.(i)Compressed suffix array (CSA): the suffix array SA of a string is an array of integers including the positions of the lexicographically sorted suffixes of ; that is, for any two integers , is lexicographically less than . The CSA is a compressed version of SA with reduced space requirements, which can perform the traditional suffix array operations with a slight slowdown. The implementation of Sadakane suffix tree that is used in our experiments utilizes the CSA presented in [10]. It is based on wavelet tree [11] built on Burrows-Wheeler transform [12]. The space consumption of this CSA is .(ii)The largest common prefix array (LCP): this is an array of integers in the range 1 to such that LCP [1] = 0 and LCP[] is the largest common prefix between [] and [], where . The LCP is also compressed. In the implementation which we use, LCP is encoded using a technique described by [7] which can store LCP in only bits.(iii)The balanced parenthesis representation (BP): BP of a tree is generated by traversing the tree in preorder manner to produce open and closed parentheses. Initially, BP is empty. Whenever a node is visited, an open parenthesis, (, is added to BP. Whenever a node is left, a close parenthesis, ), is added to BP [13]. Accordingly, each node can be encoded using 2 bits. Since suffix tree has at most internal nodes and leaves, BP takes at most bits. For example, the BP representation of the tree in Figure 1 is (()()()(()()()())()(()())(()())).
The following BP functions are used in this paper.(i): returns the number of occurrences of () in BP up to position .(ii): returns the position of the th () in BP.(iii): returns true if the position in BP belongs to a leaf.(iv): returns the position in BP for the parent node of node , where is the BP position of .(v): returns true if is a position for an open parenthesis in BP.(vi): returns the th character of the edge label of an edge pointing to node , where is the BP position of .(vii): returns the position in BP for the node which is the child of a node , where is ’s position in BP, and there is an edge directed from towards labeled by a string that starts with character .
2.3. Constructing Generalized Suffix Tree
To solve the all-pairs suffix-prefix problem for a set of strings , we build a compressed suffix tree for the string resulting by concatenating all strings together in one string. Each two concatenated strings are separated by a distinct separator. These separators do not occur in any of these strings. For example, if the strings are , , , then we build a compressed suffix tree for the text AAC#GAG$TTA%, where #, $, and % are the distinct separators. These separators should be lexicographically smaller than any character in all strings (i.e., in the alphabet ). Since, in practice, there is a limitation for the number of available distinct separators, our implementation uses more than one character to encode a separator. Assuming that there are distinct characters that can be used for constructing separators, characters are needed to encode a separator in our work.
We use an array of size to store the starting positions of the strings. The size of such array is bits, where is the size of the whole text. To map each position to the appropriate string, another array of size is needed. This array requires space of bits. To avoid the expensive cost of this array, a binary search in the array can be done to retrieve the number of the string to which a specific position belongs. However, that will increase the time cost of retrieving the string identifier to instead of time. It is easy to notice that both arrays are not necessary if the strings are equal in size. In this case, we can get the string number to which a position belongs by simply calculating , where is the length of each string.
3. Review of the Basic APSP Algorithm
The algorithm of [1] works as follows. First, the suffix tree is constructed for the string . The characters are distinct and do not exist in any of the given strings. These distinct characters are further referred to as terminal characters in this paper. Second, the suffix tree is traversed to create for each internal node a list . The list contains the children of such that each child is a leaf, and the label of the edge connecting to starts with a terminal character. Third, the suffix tree is traversed in a preorder fashion once again to report matches according to the following observation. Consider a leaf such that the string annotating the edges from the root to it is a complete given string . We call such leaf a prefix leaf. For each node on the path from the root to the prefix leaf, the prefix-suffix matches of length are those between each element in and . Accordingly, in the preorder traversal, we use stacks representing the given strings and push in stack if is in . When reaching a prefix leaf , the candidates from all parent nodes would already be in the stacks and the maximal matches are those between and the top of each stack.
4. Solutions Based on the Compressed Suffix Tree
4.1. First Method
The compressed suffix tree supports all necessary informations to run the original Algorithm of [1] as it is. However, we observe some interesting properties that could significantly improve the performance of the algorithm with no additional time or space costs.
For filling the lists, we will not simulate traversal of the whole tree over the compressed suffix tree. Rather, we will make use of the BP vector to move from a leaf to another using the function in constant time. Specifically, the function will return the position of the th () which represents a leaf. For each leaf and only if it has a terminal edge pointing to it (which can be checked using edge function), we add the text position of that leaf to the list of the parent of that leaf node. In Figure 1, we give an example, where the list for node , which is the fourth child of the root, has one value 11 that belongs to string 3. Note that we can safely ignore the first -leaves as these correspond to the terminal suffixes, where the length of each of these suffixes is a single character (one of the terminal characters).
In the case of using more than one character to encode a distinct separator, it is possible to have an internal node to which a terminal edge is pointing (usually only leaves have this possibility). Accordingly, the text position of a terminal leaf should be added to the list of its closest ancestor to which no terminal edge is pointing (see Figure 2). Let be a BP position of leaf and is the BP position of ’s parent, node . The pseudocode for the bottom-up traversal:
While is not the root and the edge pointing to is terminal,
In the second stage, we make another scan for the BP representation from left to right, but this time we move one by one (parenthesis by parenthesis) instead of jumping from leaf to leaf. We distinguish 3 cases.(i)Case 1: if the scanned node is a leaf and it is representing a starting position of a string , then the top of each stack , where and , is the longest suffix prefix match between string and string (for a proof, see [1]). We can move one step ahead since the next parenthesis is the closing parenthesis of this leaf node (lines 13–19, Algorithm 1).(ii)Case 2: if we scan an opening parenthesis for an internal node , we push each value in the list of that internal node to the appropriate stack (which can be found in time). We can determine which stack we should push the value to since this value is a text position. In Figure 1, the value 11 in will be pushed to stack 3 (lines 20–23, Algorithm 1).(iii)Case 3: if we scan a closing parenthesis for an internal node , we pop all values that belong to from the stacks. We can easily determine which stacks to pop using (lines 24–28, Algorithm 1).
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Algorithm 1 specifies our method based on the compressed suffix tree. Lines 4–10 in Algorithm 1 compute the lists as described above. We use stacks to keep track of the leaves. The second loop (lines 11–28 in Algorithm 1) mimics a preorder traversal. All ancestors of any leaf will be visited before the leaf itself, which will guarantee that all stacks for the strings will be filled before checking any leaf with a starting position. When a leaf with a starting position of a string is reached, the top of each stack will represent the longest suffix prefix match between string and string . Finally the closing parenthesis for any internal node will be reached after reaching all leaves in all subtrees of that internal node which guarantees the appropriate update (pop up) to all stacks. The two-dimensional array, Sol, will carry the solution at the end of the second loop.
4.2. Complexity Analysis
The correctness of the algorithm follows from the proof in [1]. However, in our implementation, we start the first loop with the th leaf. Since is incremented, we are moving from leaf to leaf until we reach the rightmost leaf. It is clear that all lists for all internal nodes will be filled at the end of the loop.
The construction of the generalized suffix tree consumes time [14]. We have leaves so we need time in the first loop. The second loop requires 3 steps since we have 2 parentheses for each leaf and 2 parentheses for each internal node, but we are avoiding the closing parenthesis of any leaf node by incrementing the counter by 1. In the second loop, we will have at most one push and one pop for each leaf so we have time complexity since all index operations which we are using (like isLeaf, Child, and Parent) have constant time [7]. The string to which the value on the top of a stack belongs is known since it is equal to the number of the stack, accordingly the time for outputting the results is .
As a result, the solution requires time. The complexity stands even without the usage of an array to map a position to a string (this can be done by using binary search in array), since is less than .
In term of space, we need bits to construct the tree, where is the size of the compressed suffix array [7]. Since the total number of all values in all lists is , we need bits for these lists and for the stacks. The two arrays which are mentioned in the end of Section 2 require and which are both less than . Accordingly, the solution consumes space.
4.3. Further Space Optimization
4.3.1. Space Optimization 1
It is clear the lists which are used in this method are very expensive in terms of space. One way to avoid using them is to scan the leaves once. For each leaf and only if it represents a complete string , we check every ancestor using the parent function until the root is reached. For each ancestor, we check every terminal edge which is coming from it. A terminal edge indicates a match between a prefix of and a suffix in another string. Accordingly lists are avoided and so are the stacks. Let be the maximum length of all paths from the root to all leaves (which is usually less than 1500, the maximum length for a sequence). There are at most terminal edge for each internal node, thereby the time consumption will be .
4.3.2. Space Optimization 2
Another variation for the first method is to keep the first stage as is, but in the second scan we check only the leaves. In this variation we will use the lists but we will not use the stacks. If a leaf represents a complete string , we check every ancestor of this leaf. Since the lists are filled from the first stage, the values inside the lists of the current internal node are suffix-prefix matches between and suffixes from other strings. The time complexity will be the same which is .
4.4. Second Method
The running time of the previous method can be improved based on the following two observations of [3].(i)All the distinct characters exist in the first slots in the (compressed) suffix array, because they are lexicographically less than any other character in the given strings.(ii)The terminal leaves (suffixes) sharing a prefix of length exist in the (compressed) suffix array before the other suffixes sharing also a prefix of length with them.
In this method, we scan the BP vector and move from leaf to leaf using the function. When a leaf is visited, we check if this leaf represents a suffix that is a prefix of the next leaf in BP. If it is, then it is pushed to the stack of the string which it belongs to. This continuous pushing is similar to creating the lists and copying their values to the appropriate stacks. When a prefix leaf (i.e., corresponding to a whole given string) is scanned, then all pairwise prefix-suffix matches are already in the stack. An additional stack is used to keep track of the match length. Algorithm 2 specifies how this algorithm works.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
As in the first method, we ignore parentheses which belong to separators using the Child, Rank, and Select functions. We move from leaf to leaf using the Select function (lines 1–3, Algorithm 2).
To check if a leaf is a prefix of the next leaf , we check if is a terminal leaf, and it has the same parent as the next leaf in BP. If this is the case, we push the text position of to the stack of , where is the string to which the text position of belongs (lines 32–42, Algorithm 2).
If the text position of is a starting position of a string (which can be verified using a binary search in array), then the top of each stack , where and , is the longest suffix prefix match between string and string (lines 7–11, Algorithm 2).
There is one exception for that; if there is a suffix in which matches the string and follows lexicographically the current suffix. This condition can be checked by investigating if the and both are terminal leaves, and they have the same parent. (lines 12–20, Algorithm 2).
The definition of the same parent depends on the number of characters used to encode the separators; if more than one character is used, then the parent of a leaf is the closest ancestor which does not have a terminal edge (Figure 2).
The second method has the same time complexity as the first method, since the construction of the tree requires time. For space complexity, let denote the maximum length of a sequence. We need at most of lists to hold at most values. Accordingly, bits are needed for all lists. We also need bits to store at most values in the stacks. Since is less than , the space complexity for the second method is , regardless of the usage of the array to map a position to a string.
5. Parallelizing the Algorithm
In this section, we introduce parallel versions of the above-described methods for solving the APSP problem. These versions are for shared memory multiprocessor computers. We will handle two parallelization strategies: The first, which we will call top-down decomposition is based on a straightforward top-down tree decomposition. The second, which we call leaf-decomposition is based on bottom-up decomposition.
5.1. Strategy 1: Top-Down Decomposition
The generalized suffix tree is divided into subtrees occupying the highest levels of the tree. These subtrees can be processed independently in parallel. For processors, we choose , where is a user defined parameter (We usually set it to ). The roots of these subtrees are maintained in a queue. Whenever a processor is free, then one subtree is assigned to it. Each processor executes either Algorithm 1 or Algorithm 2. The subtrees are selected by breadth-first traversal of the tree. Over the BP representation, these are selected using the child function.
For Algorithm 1, we should consider the following. Let , where , denote the string annotating the edges from the root of the generalized suffix tree to the root of th subtree. Let is the length of the longest strings. Here we distinguish between two cases: (1) the minimum match length is larger than or (2) is less than .
For the first case, the subtrees can be easily processed independently in parallel. The lists on the nodes from the root of the generalized tree to the roots of the subtrees need not to be created as the respective nodes will not be processed. A processor can start executing on a subtree without filling the stacks with the values related to its ancestors.
For the second case, we will have some lists that can be shared among two processors. For reporting the matches, there is no problem as the lists are read only. For creating them, however, we need to use only processers, where is the number of lists to be created. The stacks should be filled first with the values related to the subtree’s ancestors before executing the algorithm. In our second algorithm based on [3], the lists are not created and accordingly the above-two cases can be ignored.
In Figure 3, we give a simple example where only subtrees from the top level are pushed to the queue. Assuming that 4 processors are utilized for the problem, processor 1 will work on the first child (we ignored the children which belong to #, $, and %). Processor 1 will find the answers for string 1 which is starting with an “A,” while Processor 3 which is working on the third child of the root will find the answers for string 2 which is starting with a “G.” Processor 4 which is working on the fourth child of the root will find the answers for string 3 which is starting with a “T.” Processor 2 is not going to find any answer since none of the strings start with a “C.” No communication is required between processors for execution.
5.2. Strategy 2: Bottom-Up Decomposition
In the previous algorithm, we cannot guarantee that the subtrees are of equal sizes. Therefore, we use two tricks. First, we select subtrees, in hope of having trees of almost equal size. Second, we used a queue to keep all processors as busy as possible, which is a kind of dynamic load balancing.
Interestingly, the structure of CSA allows more robust strategy which can lead to better performance. The idea is to distribute the load equally between processors either by dividing the leaves or by dividing BP between them. Each processor starts working from the starting point of its share. It is clear that the situation is not simple; therefore, let us analyze the content of the stack for an internal node in the sequential case when the algorithm reaches that node. It can be observed that the content of each stack is whatever was pushed when visiting the node’s ancestors. All other pushing work is irrelevant since it is followed by an equivalent popping before reaching the node.
Therefore, each processor can start from a specific point if its stacks are filled with the values which would be in the stacks if we reach this point while running the sequential algorithm.
To apply this concept on the first Algorithm, let us analyze the two stages for this algorithm. The first stage is relatively trivial; each leaf, if it has a terminal edge, should push its text position to the list of its parent (or to the list of the closest ancestor which does not have a terminal edge pointing to it). Accordingly, if leaves are distributed between processors, we will have a relatively fair deal between processors.
In the second stage, BP vector will be divided equally between processors. Let be the starting parenthesis for the processor p’s share in BP (if the starting parenthesis is closing parenthesis, is the first open parenthesis which comes after the starting parenthesis). The stacks of the processor p should be filled with whatever values that would be pushed when passing through the ancestors of if we were working with the sequential algorithm. The parent function is recursively called for until the root is reached. For each ancestor of , we scan the children leaves which belongs to separators and push them in first-in-first-out way into the stacks. Each processor can then execute the algorithm on its share as if the case is sequential until the ending point of the processor’s share is reached. Figure 4 demonstrates the concept of this technique.
In the second algorithm, the leaves are divided between processors using Rank and Select. Let be the starting leaf for the processor p’s share. Again, the Parent function is recursively called until the root is reached. For each ancestor of , we scan the children leaves which belong to separators and push them in first-in-first-out way into the stacks. The algorithm then can be executed exactly as the sequential case.
5.3. Managing the Space Overhead
It is clear that both techniques use stacks for each processer, which may appear as a problem when a large number of processors are utilized. The space issue can be solved by implementing the stacks using an efficient data structure such as balanced binary search tree instead of using an array of stacks. Another solution is to use the technique presented in Section 4.3, which avoids using the stacks.
6. Experimental Results
A summary for the discussed algorithms is shown in Table 1. Experiments have been conducted to show the gain in space by comparing the space consumed by Sadakane compressed suffix tree with the space consumed by a standard pointer-based suffix tree and enhanced suffix array. We also investigated the space and time consumed in the overlap stage of a recent string graph-based sequence assembler called SGA [15]. SGA is a software pipeline for the de novo assembly of sequencing readsets. The experiments also evaluate the scalability of the proposed parallel technique and compare it with the traditional ways to parallelize a suffix tree.
To compare our work with previously presented solutions, we downloaded a solution for all-pairs suffix-prefix problem using Kurtz implementation for a standard suffix tree and the implementation presented by Ohlebusch and Gog for an enhanced suffix array from http://www.uni-ulm.de/fileadmin/website_uni_ulm/iui.inst.190/Forschung/Projekte/seqana/all_pairs_suffix_prefix_problem.tar.gz.
SGA can be downloaded from http://github.com/jts/sga/zipball/master.
In our experiments, the implementation of Sadakane compressed tree presented by Välimäki et al. ([14, 16]) is used. This implementation is tested in the work of Gog [17]. It is available at http://www.cs.helsinki.fi/group/suds/cst/cst_v_1_0.tar.gz. We used it to write two C++ solutions for the APSP problem, compiled with openMP flag to support multithreading. Our implementation is available for download at http://confluence.qu.edu.qa/download/attachments/9240580/SADAApsp.zip.
6.1. Experimental Setup
In our solutions, the user can specify the parallel technique from the command line. For each algorithm, we implement both bottom-up and top-down parallelizing techniques. The number of threads can also be given as a parameter. If the top-down technique is used, the number of threads should be , where . Another parameter is the minimal length to be accepted as a suffix-prefix match between two strings. Accordingly if the length of the longest suffix-prefix match between any two strings is less than the minimal length, then 0 is reported.
In our solution, all strings are concatenated together in one text to build a generalized suffix tree. To overcome the limitation of the number of separators, we used 3 characters to encode enough separators for strings (assuming that a character can encode around 200 separators). Our experiments for the sequential test were run on machines having Linux Ubuntu version 11.10, 32-bit with 3 GB RAM, Intel 2.67 GHZ CPU, and 250 GB hard disk.
Our results are obtained by running against randomly generated as well as real data. The random data were generated by a program that outputs random strings with random lengths, but with a total length of , where and are specified by the user. The random numbers were drawn from a uniform distribution. The real data, which are the complete EST database of C. elegans, are downloaded from: http://www.uni-ulm.de/in/theo/research/seqana. The size of the total length for the real data is 167,369,577 bytes with strings. We use the average of 5 readings for each data point. Table 2 describes our data sets.
To test our parallel technique, we used Amazon Web services (AWS) to obtain an instance with 16 cores. Our parallel implementation uses the OpenMP library.
6.2. Experimental Evaluation
Experimental results demonstrate that the first method uses around one-third of the space used by a standard pointer-based suffix tree to solve the same problem, while the second method uses less than one-fifth of the space consumed by a standard suffix tree (see Figure 5). We interpret the difference in space consumption between the two methods as a consequence of the difference in space complexity and the difference in number of the lists that are used in the two methods.
However, this gain in space has some consequences. Figure 6 demonstrates an obvious slowdown of our solution, which is an expected price to pay as a result of using a compressed data structure. Nevertheless, we were able to run our tests using Sadakane compressed suffix tree with a text of a length that is larger than 300 MB, while the maximum size of text which we could run our test on, using a standard suffix tree or an enhanced suffix array, was 90 MB. Therefore, our solution offers better utilization of space resources and allows the user to run larger jobs without the need to upgrade hardware. In addition, our solutions overcome the practical total number of strings limitation (i.e., is not limited to 200).
Despite the impressive space consumption of SGA, our solutions consume less time than SGA. In addition, the performance of SGA depends dramatically on two factors: the maximum length of a sequence and the minimal length of a match. Since the time complexity of our solution depends on where is the total length of all strings, both factors do not affect the performance in our solutions. Our results show that SGA fails to create its index for the overlap stage when , where is the maximum length of a sequence.
The parallel tests show the following: with random data, all techniques take around 24–26% and 9–11% of the time required by the sequential test, with 4 and 16 cores, respectively. Figures 7 and 8 show that both techniques demonstrate good scalability. No significant difference in performance is observed between the two methods.
With real data, the bottom-up technique achieves a speedup of 11–13% compared with the performance of the top-down technique. It is also noticable that the second method [3] consumes with real data more time than the first method [1] (Figure 9). This is due to the fact that the real data has a considerable number of strings which are suffixes of others, which causes the special case (exception) in method 2 to occur frequently.
7. Conclusion
This paper provides two solutions for the all-pairs suffix-prefix problem using Sadakane compressed suffix tree, which reduce the expensive cost of suffix tree in term of space. In spite of significant slowdown in performance, it is clear that the proposed solutions may be preferred when dealing with huge sizes of data because of its modest space requirement. To reduce the performance overhead, the paper presented static and new dynamic techniques to parallelize the proposed solutions. The bottom-up technique performs more efficiently when real data is used, while both techniques perform equally with random data. The presented solutions are not limited to cases with a small number of strings. SGA is superior in terms of space, but it consumes more time than the presented solutions and it does not handle sequences which have large lengths. The paper has demonstrated that it is beneficial to use an enhanced suffix array to solve APSP. It could be worthwhile to explore solving the problem using a compressed suffix array and a compressed largest common prefix (LCP) array by adapting the algorithm presented by Ohlebusch and Gog, which makes the topic a good subject for future study.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgment
This publication was made possible by NPRP Grant no. 4-1454-1-233 from the Qatar National Research Fund (a member of Qatar Foundation). The statements made herein are solely the responsibility of the authors.