O’Reach: Even Faster Reachability in Large Graphs

4.1 Extended Topological Orderings

Taking up the observation that topological orderings can be used to answer a reachability query decisively negative, we first investigate how Observation (B4) can be used most effectively in practice. Before we dive deeper into this subject, let us briefly review some facts concerning topological orderings and reachability in general.

In consequence, it is pointless to look for one particularly good topological ordering. Instead, to get the most out of Observation (B4), we need topological orderings whose sets of answerable negative queries differ greatly, such that their union covers a large fraction of \( \mathcal {N} \). Note that both forward and backward topological levels each represent the set of topological orderings that can be obtained by ordering the vertices in blocks grouped by their level and arbitrarily permuting the vertices in each block. Different algorithms [6, 19, 29] for computing a topological ordering in linear time have been proposed over the years, with Kahn’s algorithm [19] in combination with a queue being one that always yields a topological ordering represented by forward topological levels. We, therefore, complement the forward and backward topological levels by stack-based approaches, as in Kahn’s algorithm [19] in combination with a stack or Tarjan’s DFS-based algorithm [29] for computing the SCCs of a graph, which as a by-product also yields a topological ordering of the condensation. To diversify the set of answerable negative queries further, we additionally randomize the order in which vertices are processed in case of ties and also compute topological orderings on the reverse graph, in analogy to backward topological levels.

We next show how, with a small extension, the stack-based topological orderings mentioned above can be used to additionally answer positive queries. To keep the description concise, we concentrate on Tarjan’s algorithm [29] in the following and reduce it to the part relevant for obtaining a topological ordering of a DAG. In short, the algorithm starts a DFS at an arbitrary vertex \( s \in S \), where \( S \subseteq V \) is a given set of vertices to start from. Whenever it visits a vertex v, it marks v as visited and recursively visits all unvisited vertices in its out-neighborhood. On return, it prepends v to the topological ordering. A loop over \( S = V \) ensures that all vertices are visited. Note that although the vertices are visited in DFS order, the topological ordering is different from a DFS numbering as it is constructed “from back to front” and corresponds to a reverse sorting according to what is also called finishing time of each vertex.

To answer positive queries, we exploit the invariant that when visiting a vertex v, all yet unvisited vertices reachable from v will be prepended to the topological ordering prior to v being prepended. Consequently, v can certainly reach all vertices in the topological ordering between v and, exclusively, the vertex w that was at the front of the topological ordering when v was visited. Let x denote the vertex preceding w in the final topological ordering, i.e., the vertex with the largest index that was reached recursively from v. For a topological ordering \( \tau \) constructed in this way, we call \( \tau (x) \) the high index of v and denote it with \( \tau _H(v) \). Furthermore, v may be able to also reach w and vertices beyond, which occurs if \( v \rightarrow ^*y \) for some vertex y, but y had already been visited earlier. We, therefore, additionally track the max index, the largest index of any vertex that v can reach, and denote it with \( \tau _{X}(v) \). Figure 1(a) shows how to compute an extended topological ordering with both high and max indices in pseudo-code and highlights our extensions. Compared to Tarjan’s original version [29], the running time remains unaffected by our modifications and is still in \( \mathcal {O}(n+m) \).

Fig. 1.

View Figure

Note that neither max nor high indices yield an ordering of V: Every vertex that is visited recursively starting from v and before vertex x with \( \tau (x) = \tau _H(v) \), inclusively, has the same high index as v, and the high index of each vertex in a graph consisting of a single path, e.g., would be n – 1. In particular, neither max nor high index forms a DFS numbering and also differ in definition and use from the DFS finishing times \( \hat{\phi } \) used in PReaCH, where a vertex v can certainly reach vertices with DFS number up to \( \hat{\phi } \) and certainly none beyond. Conversely, v may be able to also reach vertices with a smaller DFS number than its own, which cannot occur in a topological ordering.

If ExtendedTopSort is run on the reverse graph, it yields a topological ordering \( \tau ^{\prime } \) and high and max indices \( \tau ^{\prime }_H \) and \( \tau ^{\prime }_{X} \), such that reversing \( \tau ^{\prime } \) yields again a topological ordering \( \tau \) of the original graph. Furthermore, \( \tau _L(v) := n - 1 - \tau ^{\prime }_H(v) \) is a low index for each vertex v, which denotes the smallest index of a vertex in \( \tau \) that can certainly reach v, i.e., the out-reachability of v is replaced by in-reachability. Analogously, \( \tau _{N}(v) := n - 1 - \tau ^{\prime }_{X}(v) \) is a min index in \( \tau \) and no vertex u with \( \tau (u) \lt \tau _{N}(v) \) can reach v.

The following observations show how such an extended topological ordering \( \tau \) can be used to answer both positive and negative reachability queries:

Recall that by definition, \( \tau (s) \le \tau _H(s) \le \tau _{X}(s) \) and \( \tau _{N}(t) \le \tau _L(t) \le \tau (t) \). Figure 1(b) depicts three examples of extended topological orderings. In contrast to negative queries, not every extended topological ordering is equally effective in answering positive queries, and it can be arbitrarily bad, as shown in the extremes on the left (worst) and at the center (best) of Figure 1(b):

Instead, the effectiveness of an extended topological ordering depends positively on the size of the ranges \( \left[\tau (v), \tau _H(v)\right] \) and \( \left[\tau _L(v), \tau (v)\right] \), and negatively on \( \left[\tau _H(v), \tau _{X}(v)\right] \) and \( \left[\tau _{N}(v), \tau _L(v)\right] \) which in turn depend on the recursion depths during construction and the order of recursive calls. The former two can be maximized if the first, non-recursive call to Visit() in line 4 in ExtendedTopSort always has a source as its argument, i.e., if the algorithm’s parameter S corresponds to the set of all sources. Clearly, this still guarantees that every vertex is visited.

In addition to the forward and backward topological levels, O’Reach thus computes a set of d extended topological orderings starting from sources, where d is a tuning parameter, and \( d/2 \) of them are obtained via the reverse graph. It then applies Observation (B4) as well as Observations (T1)–(T6) to all extended topological orderings.

4.2 Supportive Vertices

We now show how to apply and improve the idea of supportive vertices in the static setting. A vertex v is supportive if the set of vertices that v can reach and that can reach v, \( {R^{+}}(v) \) and \( {R^{-}}(v) \), respectively, have been precomputed and membership queries can be performed in sublinear time. We can then answer reachability queries using the following simple observations [11]:

To apply these observations, our algorithm selects a set of k supportive vertices during the initialization phase. In contrast to the original use scenario in the dynamic setting, where the graph changes over time and it is difficult to choose “good” supportive vertices that can help to answer many queries, the static setting leaves room for further optimizations here: With respect to Observation (S1), we consider a supportive vertex v “good” if \( |{R^{+}}(v)| \cdot |{R^{-}}(v)| \) is large as it maximizes the possibility that \( s \in {R^{-}}(v) \wedge t \in {R^{+}}(v) \). With respect to Observation (S2) and (S3), we expect a “good” supportive vertex to have out- or in-reachability sets, respectively, of size close to \( \frac{n}{2} \), i.e., when \( |{R^{+}}(v)|\cdot |V \setminus {R^{+}}(v)| \) or \( |{R^{-}}(v)|\cdot |V \setminus {R^{-}}(v)| \), respectively, are maximal. Furthermore, to increase total coverage and avoid redundancy, the set of queries Query(\( s, t \)) covered by two different supportive vertices should ideally overlap as little as possible.

O’Reach takes a parameter k specifying the number of supportive vertices to pick. Intuitively speaking, we expect vertices in the topological “mid-levels” to be better candidates than those at the ends, as their out- and in-reachabilities (or non-reachabilities) are likely to be more balanced. Furthermore, if all vertices on one forward (backward) level i were supportive, then every Query(\( s, t \)) with \( \mathcal {F}(s) \lt i \lt \mathcal {F}(t) \) (\( \mathcal {B}(t) \lt i \lt \mathcal {B}(s) \)) could be answered using only Observation (S1). As finding a “perfect” set of supportive vertices is computationally expensive and we strive for linear preprocessing time, we experimentally evaluated different strategies for the selection process. Due to page limits, we only describe the most successful one: A forward (backward) level i is called central, if \( \frac{1}{5}L_{\max } \le i \le \frac{4}{5}L_{\max } \), where \( L_{\max } \) is the maximum topological level. A level i is called slim if there are at most h vertices having this level, where h is a parameter to O’Reach. We first compute a set of candidates of size at most \( k\cdot p \) that contains all vertices on the slim forward or backward levels, arbitrarily discarding vertices as soon as the threshold \( k\cdot p \) is reached. p is another parameter to O’Reach and together with k controls the size of the candidate set. If the threshold is not reached, we fill up the set of candidates by picking the missing number of vertices uniformly at random from all other vertices whose forward level is central. In the next step, the out- and in-reachabilities of all candidates are obtained and the k vertices v with the largest \( |{R^{+}}(v)| \cdot |{R^{-}}(v)| \) are chosen as supportive vertices. This strategy primarily optimizes for Observation (S1), but worked better in experiments than strategies that additionally tried to optimize for Observations (S2) and (S3). The time complexity of this process is in \( \mathcal {O}(kp(n+m) + kp\log (kp)) \).

We remark that this is a general-purpose approach that has shown to work well across different types of instances, albeit possibly at the expense of an increased initialization time. It seems natural that more specialized routines for different graph classes can improve both running time and coverage.

4.3 The Complete Algorithm

Given a graph G and a sequence of queries Q, we summarize in the following how O’Reach proceeds. During initialization, it performs the following steps:

Steps 1 and 2 run in linear time. As shown in Sections 4.1 and 4.2, the same applies to Steps 3 and 4, assuming that all parameters are constants. The required space is linear for all steps. The reachability index consists of the following information for each vertex v: one integer for the WCC, one integer each for \( \mathcal {F}(v) \) and \( \mathcal {B}(v) \), three integers for each of the d extended topological orderings \( \tau \) (\( \tau (v), \tau _H(v)/\tau _L(v), \tau _{X}(v)/\tau _{N}(v) \)), two bits for each of the k supportive vertices, indicating its reachability to/from v. For graphs with and \( n \le 2^{32} \), \( 4 \,{\text{Byte}} \) per integer suffice. Furthermore, we group the bits encoding the reachabilities to and from the supportive vertices, respectively, and represent them each by one suitably sized integer, e.g., using uint8_t (\( 8 \,\rm bit \)), for \( k\le 8 \) supportive vertices. As the smallest integer has at least \( 8 \,\rm bit \) on most architectures, we store \( {12 + 12 d{} + 2 \cdot \lceil \frac{k}{8}\rceil } \,{\text{Byte}} \) per vertex.

For each query Query(\( s, t \)), O’Reach tries to answer it using one of the observations in the order given below, which on the one hand has been optimized by some preliminary experiments on a small subset of benchmark instances (see Section 5 for details) and on the other hand strives for a fair alternation between “positive” and “negative” observations to avoid overfitting. Note that all observation-based tests run in constant time. As soon as one of them can answer the query affirmatively, the result is returned immediately. A test leading to a positive or negative answer is marked as or , respectively.

Observe that the tests for Observations (S1)–(S3) can each be implemented easily using boolean logic, which allows for a concurrent test of all supports whose reachability information is encoded in one accordingly-sized integer: For Observation (S1), it suffices to test whether \( r^-(s) \wedge r^+(t) \gt 0 \), and \( r^+(s) \wedge \lnot r^+(t) \gt 0 \) and \( \lnot r^-(s) \wedge r^-(t) \gt 0 \) for Observations (S2) and (S3), where \( r^+ \) and \( r^- \) hold the respective forward and backward reachability information in the same order for all supports. Each test hence requires at most one comparison of two integers plus at most two elementary bit operations. Also, note that Observation (B1) is implicitly tested by Observations (B5) and (B6). Using the data structure described above, our algorithm requires at most one memory transfer for s and one for t for each Query(\( s, t \)) that is answerable by one of the observations. Note that there are more observations that allow to identify a negative query than a positive query, which is why we expect a more pronounced speedup for the former. However, as stated in Theorem 4.1, the reachability in DAGs is always less than 50%, which justifies a bias towards an optimization for negative queries.

If the query can not be answered using any of these tests, we instead fall back to either another algorithm or a bidirectional BFS with pruning, which uses these tests for each newly encountered vertex v in a subquery Query(\( v, t \)) (forward step) or Query(\( s, v \)) (backward step). If a subquery can be answered decisively positive by a test, the bidirectional BFS can immediately answer Query(\( s, t \)) positively. Otherwise, if a subquery is answered decisively negative by a test, the encountered vertex v is no longer considered (pruning step). If the subquery could not be answered by a test, the vertex v is added to the queue as in a regular (bidirectional) BFS.

5.1 Setup and Methodology

We implemented O’Reach in C++ 14² with pBiBFS as a built-in fallback strategy. For PPL,³TF,³ PReaCH,⁴ IP,⁵ and BFL⁶ we used the original C++ implementation in each case. All source code was compiled with GCC 7.5.0 and full optimization (-O3). The experiments were run on a Linux machine under Ubuntu 18.04 with kernel 4.15 on four AMD Opteron 6174 CPUs clocked at \( 2.2 \,\mathrm{G}\mathrm{Hz} \) with \( 512 \,\mathrm{k}{\rm B} \) and \( 6 \,\mathrm{M}{\rm B} \) L2 and L3 cache, respectively, and 12 cores per CPU. Overall, the machine has 48 cores and a total of \( 256 \,\mathrm{G}{\rm B} \) of RAM. Unless indicated otherwise, each experiment was run sequentially and exclusively on one processor and its local memory. As non-local memory accesses incur a much higher cost, an exception to this rule was only made for Matrix, where we would otherwise have been able to only run twelve instead of 29 instances. We also parallelized the initialization phase for Matrix, where the transitive closure is computed, using 48 threads. However, all queries were processed sequentially.

To counteract artifacts of measurement and accuracy, we ran each algorithm five times on each instance and in general use the median for the evaluation. As O’Reach uses randomization during initialization, we instead report the average running time over five different seeds. For IP and BFL, which are randomized in the same way, but do not accept a seed, we just give the average over five repetitions. We note that also taking the median instead or increasing the number of repetitions or seeds does not change the overall picture.

Instances. To facilitate comparability, we adopt the instances used in the articles introducing PReaCH [22] and TF [3], which overlap with those used to evaluate IP [36] and BFL [28], and which are available either from the GRAIL code repository ⁷ or the Stanford Network Analysis Platform SNAP [21]. Furthermore, we extended the set of benchmark graphs by further instance sizes and Delaunay graphs. Table A.4 provides a detailed overview. As we only consider DAGs, all instances are condensations of their respective originals, if they were not acyclic already. We also adopt the grouping of the instances as in [22, 39] and provide only a short description of the different sets in the following.

Kronecker. These instances were generated by the RMAT generator for the Graph500 benchmark [23] and oriented acyclically from smaller to larger node ID. The name encodes the number of vertices \( 2^i \) as kron_logni. Random: Graphs generated according to the Erdős-Renyí model \( G(n, m) \) and oriented acyclically from smaller to larger node ID. The name encodes \( n=2^i \) and \( m=2^j \) as randni-j. Delaunay: Delaunay graphs from the 10th DIMACS Challenge [1, 8]. delaunay_ni is a Delaunay triangulation of \( 2^{i} \) random points in the unit square. Large real: Introduced in [39], these instances represent citation networks (citeseer.scc, citeseerx, cit-Patents), a taxonomy graph (go-uniprot), as well as excerpts from the RDF graph of a protein database (uniprotm22, uniprotm100, uniprotm150). Small real dense: Among these instances, introduced in [17], are again citation networks (arXiv, pubmed_sub, citeseer_sub), a taxonomy graph (go_sub), as well as one obtained from a semantic knowledge database (yago_sub). Small real sparse: These instances were introduced in [18] and represent XML documents (xmark, nasa), metabolic networks (amaze, kegg) or originate from pathway and genome databases (all others). SNAP: The e-mail network graph (e-mail-EuAll), peer-to-peer network (p2p-Gnutella31), social network (soc-LiveJournal1), web graph (web-Google), as well as the communication network (wiki-Talk) are part of SNAP and were first used in [3].

Queries. Following the methodology of [22], we generated three sets of 100,000 queries each: positive, negative, and random. Each set consists of random queries, which were generated by picking two vertices uniformly at random and filtering out negative or positive queries for the positive and negative query sets, respectively. The fourth query set, mixed, is a randomly shuffled union of all queries from positive and negative and hence contains 200,000 pairs of vertices. As the order of the queries within each set had an observable effect on the running time due to caching effects and memory layout, we randomly shuffled every query set five times and used a different permutation for each repetition of an experiment to ensure equal conditions for all algorithms.

5.2 Experimental Results

We ran O’Reach with \( k= 16 \) supportive vertices, picked from 1,200 candidates (\( p= 75 \), \( h=8 \)) and \( d= 4 \) extended topological orderings. We ran IP with the two configurations used also by the authors [36] and refer to the resulting algorithms as IP(s) (sparse, \( h_{\texttt {IP}}{}= k_{\texttt {IP}}{} = 2 \)) and IP(d) (dense, \( h_{\texttt {IP}}{}= k_{\texttt {IP}}{} = 5 \)). Similarly, we evaluated BFL [28] with configuration sparse as BFL(s) (\( s_{\texttt {BFL}}{}=64 \)) and dense as BFL(d) (\( s_{\texttt {BFL}}{}=160 \)), following the presets given by the authors.

Average query times. Table A.5 lists the average time per query for the query sets negative and positive. All missing values are due to a memory requirement of more than \( 32 \,\mathrm{G}{\rm B} \) (TF) and Matrix (\( 256 \,\mathrm{G}{\rm B} \)). For each instance and query set, the running time of the fastest algorithm is printed in bold. If Matrix was fastest, also the running time of the second-best algorithm is highlighted. Besides Matrix, the table shows the running times of PReaCH, PPL, IP(d), and BFL(d) alone as well as multiple versions for O’Reach: one with a pruned bidirectional BFS (O’R +pBiBFS) as fallback as well as one per competitor (O’R +...), where O’Reach was run without fallback and the queries left unanswered were fed to the competitor. Analogously, the running times for IP(s), BFL(s), and TF alone and as a fallback for O’Reach are given in Table A.7.

Our results by and large confirm the performance comparison of PReaCH, PPL, and TF conducted by Merz and Sanders [22]. PReaCH was the fastest on three out of five Kronecker graphs for the negative query set, once beaten by O’R +PReaCH and O’R +PPL each, whereas PPL and O’R +PPL dominated all others on the positive query set in this class as well as on three of the five random graphs, while O’R +TF was slightly faster on the other two. In contrast to the study in [22], TF is outperformed slightly by PPL on random instances for the positive query set. PReaCH was also the dominating approach on the small real sparse and SNAP instances in the aforementioned study [22]. By contrast, it was outperformed on these classes here by O’Reach with almost any fallback on all instances for the positive query set, and by either IP(d) or BFL(s) on almost all instances for the negative query set. On the Delaunay and large real instances, BFL(s) often was the fastest algorithm on the set of negative queries. The results also reveal that BFL and in particular IP have a weak spot in answering positive queries. On average over all instances, O’R +PPL had the fastest average query time both for negative and positive queries.

Notably, \( \texttt {Matrix}{} \) was outperformed quite often, especially for queries in the set negative, which correlates with the fact that a large portion of these queries could be answered by constant-time observations (see also the detailed analysis of observation effectiveness below) and is due to its larger memory footprint. Across all instances and seeds, more than \( 95 \,\% \) of all queries in this set could be answered by O’Reach directly. On the set positive, the average query time for Matrix was in almost all cases less than on the negative query set, which is explained by the small reachability of the instances and a resulting higher spatial locality and better cacheability of the few and naturally clustered one-entries in the matrix. Consequently, this effect was distinctly reduced for the mixed query set, as shown in Table A.6.

There are some instances where O’Reach had a fallback rate of over \( 90 \,\% \) for the positive query set, e.g., on cit-Patents, which is clearly reflected in the running time. Except for PPL, all algorithms had difficulties with positive queries on this instance. Conversely, the fallback rate on all uniprotenc_\( {}^* \) instances and citeseer.scc, e.g., was \( 0 \,\% \). On average across all instances and seeds, O’Reach could answer over \( 70 \,\% \) of all positive queries by constant-time observations.

The results on the query sets random and mixed are similar and listed in Tables A.6 and A.8. Once again, O’R +PPL showed the fastest query time on average across all instances for both query sets. As the reachability in a DAG is low in general (see also Theorem 4.1) and particularly in the benchmark instances, the average query times for random resemble those for negative. On the other hand, the results for the mixed query set are more similar to those for the positive query set, as the relative differences in performance among the algorithms are more pronounced there. Table 2 compactly shows the average query time over all instances for each query set. Only PPL and O’R +PPL achieved an average query time of less than \( 1 \,\mathrm{\mu }\mathrm{s} \) (and even less than \( 0.35 \,\mathrm{\mu }\mathrm{s} \)).

Table 2.

View Table

Table 2. Average Query Time Per Algorithm and Query Set

Speedups by O’Reach . We next investigate the relative speedup of O’Reach with different fallback solutions over running only the fallback algorithms. Table A.9 lists the ratios of the average query time of each competitor algorithm run standalone divided by the average query time of O’Reach plus that algorithm as fallback, for all four query sets. A compact version is also given in Table 3. In the large majority of cases, using O’Reach as a preprocessor resulted in a speedup, except in case of negative or random queries for BFL and partially IP on the large real instances as well as for PReaCH and partially again IP on the small real sparse and SNAP instances. The largest speedup of around 105 could be achieved for BFL on kegg for random queries. The mean speedup (geometric) is at least \( 1.29 \) for all fallback algorithms on the query sets positive, random, and mixed, where the maximum was reached for IP(s) on positive queries with a factor of \( 4.21 \). Only for purely negative queries, IP(d) and BFL(s) were a bit faster alone in the mean values. Figure 2 gives some more insight into the distribution of the values and shows that the combination with O’Reach led to distinct speedups for all algorithms on a large majority of the instances on the positive and mixed query set, and also for random. For the negative query set, the combination with O’Reach could in particular speed up the average query time for PPL on all instances, for TF on more than \( 75 \,\% \) of the instances, and for PReaCH and BFL(d) still on around half of the instances. In summary, given that the algorithms are often already faster than single memory lookups, the speedups achieved by O’Reach are quite high.

Fig. 2.

View Figure

Table 3.

• Values greater \( 1.00 \) are highlighted.

View Table

Table 3. Mean Speedups with O’Reach Plus Fallback Over Pure Fallback Algorithm

• Values greater \( 1.00 \) are highlighted.

Initialization Times (Table A.10). On all graphs, BFL(s) had the fastest initialization time, followed by BFL(d) and PReaCH. For O’Reach, the overhead of computing the comparatively large out- and in-reachabilities of all 1,200 candidates for \( k=16 \) supportive vertices is clearly reflected in the running time on denser instances and can be reduced greatly if lower parameters are chosen, albeit at the expense of a slightly reduced query performance, e.g., for \( k=8 \). PPL often consumed a lot of time in this step, especially on denser instances, with a maximum of \( 2.6 \,\mathrm{h} \) on randn20-23.

Based on the average query time per instance, the minimum number of random queries necessary to amortize the additional investment in initialization time if O’Reach is run as preprocessor is between \( 9.6 \) thousand (O’R +BFL(d)) and 499 thousand (O’R +PReaCH). Counting cases where O’Reach could not achieve a speedup in the average query time as infinity, the median number of random queries required for amortization is between \( 2.5 \) million (O’R +BFL(d)) and 101 million (O’R +IP(d)). For the on average fastest algorithm, O’R +PPL, the initialization cost is recovered after 210 thousand (nasa) to \( 6.15 \) billion (kron_logn21) random queries, which equals about \( 0.77 \,\% \) (nasa) and \( 0.14 \,\% \) (kron_logn21) of all vertex pairs, respectively.

Effectiveness of Observations. We collected a vast amount of statistical data to perform an analysis of the effectiveness of the different observations used in O’Reach. To make the analysis more robust, we added additional seeds and increased the number to 25 here. For each observation, we maintained a separate counter, which was increased whenever a query could be answered by an observation. If an observation included multiple tests, as in case of those based on topological orderings ((B4), (T1)–(T6)) or on supportive vertices ((S1)–(S3)), the counter was only increased once per observation, even if, e.g., (B4) applied for two topological orderings or (S1) applied for multiple supportive vertices. We then obtained the average effectiveness for each observation as the mean ratio of the counter value over the number of queries we want to consider, taken over all seeds and all instances.⁸ The results are also shown in Table A.12.

First, we look only at fast queries, i.e., those queries that could be answered without a fallback. We increased the counter for all observations that could answer a query for this analysis, not just the first in order, which is why there may be overlaps (one query can be answered multiple times). Across all query sets, the most effective observation was the negative basic observation on topological orderings, (B4), which could answer \( 54 \,\% \) of all fast queries. As the average reachability in the random query set is very low, negative queries predominate in the overall picture. It thus does not come as a surprise that the most effective observation is a negative one. On the negative query set, it could answer even \( 84 \,\% \) of all fast queries. The negative observations second to (B4) in effectiveness were those looking at the forward and backward topological levels, Observation (B5) and (B6), which could answer around \( 74.5 \,\% \) each on the negative query set and around \( 47.5 \,\% \) of all fast queries. The observations using the max and min indices of extended topological orderings, (T2) and (T5), could answer \( 26 \,\% \) and \( 19 \,\% \) of the fast queries in the negative query set, and the observations based on supportive vertices, (S2) and (S3), \( 19 \,\% \) and \( 12 \,\% \), respectively.

After lowering the number of topological orderings from \( d= 4 \) to \( d= 2 \), (B4) was equally effective as (B5) and (B6), each of which could answer around \( 48 \,\% \) of all fast queries and \( 75 \,\% \) of those in the negative query set. Observe that decreasing d negatively affects the number of fast queries, which in turn leads to slightly increased ratios for (B5) and (B6). For Observations (T2) and (T5), the effectiveness was reduced to \( 21 \,\% \) and \( 16 \,\% \) on the negative query set, and to \( 13 \,\% \) and \( 10 \,\% \) across all query sets.

The most effective positive observation and the second-best among all query sets, was the supportive-vertices-based Observation (S1), which could answer around \( 25 \,\% \) of all fast queries and \( 66 \,\% \) in the positive query set. Follow-up observations were the ones using high and low indices, (T1) and (T4), with \( 21 \,\% \) and \( 23 \,\% \) effectiveness for the positive query set, and around \( 7.5 \,\% \) across all query sets. The remaining two, (T3) and (T6), could answer \( 10 \,\% \) and \( 5 \,\% \) in the positive set.

Reducing the number of supportive vertices from \( k= 16 \) to \( k= 8 \) led to a small diminution of the effectiveness of Observation (S1) to around \( 64.5 \,\% \) on the set of positive queries, both if the number of candidates to choose from was kept equal (\( p= 150 \)) or reduced analogously (\( p= 75 \)). Reducing the number of topological orderings to \( d= 2 \) resulted in a slight deterioration in case of (T1) and (T4) to \( 19 \,\% \) and \( 21 \,\% \), and to \( 5 \,\% \) with respect to the positive query set.

Among all fast queries that could be answered by only one observation, the most effective observation was the positive supportive-vertices-based Observation (S1) with \( 38 \,\% \) for all query sets and \( 65 \,\% \) for the positive query set, followed by the negative basic observation using topological orderings, (B4), with around \( 29 \,\% \) for all query sets and \( 63 \,\% \) for the negative query set.

Looking now at the entire query sets, our statistics show that \( 95 \,\% \) of all queries could be answered via an observation on the negative set. In \( 70 \,\% \) of all cases, (B5) in the second test, which uses topological forward levels, could already answer the query. In further \( 16 \,\% \) of all cases, the observation based on topological backward levels, (B6), was successful. On the positive query set, the fallback rate was around \( 29 \,\% \) and hence higher than on the negative query set. \( 52 \,\% \) of all queries in this set could be answered by the supportive-vertices-based observation (S1), and the high and low indices of extended topological orderings (T1) and (T4) were responsible for another \( 7 \,\% \) and \( 4 \,\% \), respectively. Observe that here, the first observation in the order that can answer a query “wins the point”, i.e., the effectiveness here depends on the order and there are no overlaps in the reported effectiveness.

Memory Consumption. Table A.11 lists the memory each algorithm used for their reachability index. As O’Reach was configured with \( k= 16 \) and \( d= 4 \), its index size is \( 64n \,{\text{Byte}} \). Consequently, the reachability indices of O’Reach, PReaCH, PPL, IP, BFL, and, with one exception for TF, fit in the L3 cache of \( 6 \,\mathrm{M}{\rm B} \) for all small real instances. For Matrix, this was only the case for the four smallest instances from the small real sparse set, three of the small real dense ones, and the smallest Kronecker graph, which is clearly reflected in its average query time for the negative, random, and, to a slightly lesser extent, mixed query sets. Whereas for O’Reach, PReaCH, and Matrix, the index size depends solely on the number of vertices, IP, BFL, PPL, and TF consumed more memory the larger the density \( \frac{m}{n} \). IP(s) usually was the most space-efficient and never used more than \( 395 \,\mathrm{M}{\rm B} \), followed by BFL(s) (\( 429 \,\mathrm{M}{\rm B} \)), IP(d) (\( 440 \,\mathrm{M}{\rm B} \)), BFL(d) (\( 754 \,\mathrm{M}{\rm B} \)), PReaCH (\( 1.3 \,\mathrm{G}{\rm B} \)), O’Reach (\( 1.5 \,\mathrm{G}{\rm B} \)), and PPL (\( 4.4 \,\mathrm{G}{\rm B} \)). All these algorithms are hence suitable to handle graphs with several millions of vertices even on hardware with relatively little memory (with respect to current standards). TF used up to \( 3.8 \,\mathrm{G}{\rm B} \) (randn23-25), but required even more than \( 64 \,\mathrm{G}{\rm B} \) at least during initialization on all instances where the data is missing in the table.