Optimizing Function Layout for Mobile Applications

As mobile apps continue to grow rapidly, reducing the binary size is crucial for application developers (Lee et al., 2022a; Bhatia, 2021; Liu et al., 2022). Smaller apps can be downloaded faster, which directly impacts user experience (Reinhardt, 2016). For example, a recent study in (Chabbi et al., 2021) establishes a strong correlation between the app size and the user engagement. Furthermore, mobile app distribution platforms may impose size limitations for downloads that use cellular data (Chabbi et al., 2021). Indeed, in the Apple App Store, when an app’s size crosses a certain threshold, users will not get timely updates, which often include critical security improvements, until they are connected to a Wi-Fi network.

Mobile apps are distributed to users in a compressed form via the mobile app platforms. Typically, application developers do not have a direct control over the compression technique utilized by the platforms. However, the recent work of Lee, Hoag, and Tillmann (Lee et al., 2022a) observes that by modifying the content of a binary, one may improve its compressed size. In particular, co-locating “similar” functions in the binary improves the compression ratio achieved by popular compression algorithms such as ZSTD or LZFSE. A similar technique, co-locating functions based on their similarity, is utilized in Redex, a bytecode Android optimizer (Inc, 2021).

Why does function layout affect compression ratios? Most modern lossless compression tools rely on the Lempel-Ziv (LZ) scheme (Ziv and Lempel, 1977). Such algorithms try to identify long repeated sequences in the data and substitute them with pointers to their previous occurrences. If the pointer is represented in fewer bits than the actual data, then the substitution results in a compressed-size win. That is, the shorter the distance between the repeated sequences, the higher the compression ratio is. To make the computation effective, LZ-based algorithms search for common sequences inside a sliding window, which is typically much shorter than the actual data. Therefore, function layouts in which repeated instructions are grouped together, lead to smaller (compressed) mobile apps; see Figure 1 for an example. In Section 2 we describe an algorithmic framework for finding such layouts.

Start-up time is one of the key metrics for mobile applications. Launching an app quickly is important to ensure users have a good first impression. Start-up delays have a direct impact on user engagement (Yan et al., 2012). A study in (Mansour, 2020) indicates that $20\%$ of users abandon an app after one use and $80\%$ of them give a poorly performing app three chances or fewer before uninstalling it.

Start-up time is the time between a user clicking on an application icon to the display of the first frame after rendering. There are several start-up scenarios: cold start, warm start, and hot start (Inc., 2022; Developers, 2022; Inc., 2015). Switching back and forth between different apps on a mobile leads to hot/warm start and typically does not incur significant delays. In contrast, starting an app from scratch or resuming it after a memory intensive process is referred to as cold start. Our main focus is on improving this cold start scenario, which is usually the key performance metric.

Unlike server workloads, where code layout algorithms optimize the cache utilization (Ottoni and Maher, 2017; Panchenko et al., 2019; Newell and Pupyrev, 2020), start-up performance is mostly dictated by memory page faults (Easton and Fagin, 1978). When an app is launched, its code has to be transferred from disk to the main memory before it can be executed. Function layout can affect performance because the transfer happens at the granularity of memory pages. As illustrated in Figure 2, interleaving cold functions that are never executed with hot ones results in more memory pages to fetch from disk. A tempting solution is to group together hot functions in the binary. Notice however that some mobile apps have a billion of daily active users who use the apps on a variety of devices and platforms. Thus, optimizing the layout for one usage scenario might result in sub-optimal performance for others. The main challenge is to produce a single function layout that optimizes the start-up performance across all use cases. This is accomplished by a novel optimization model, which we develop in Section 2.

We model the problem of computing an optimized function layout for mobile apps as the balanced graph partitioning problem (Garey et al., 1974). The approach allows for a single algorithm that can improve both app start-up time (impacting user experience) and app size (impacting download speed). However, while the layout algorithm is the same for the objectives, it operates with different data collected while profiling the binary. For the sake of clarity, we call the optimizations Balanced Partitioning for Start-up Optimization (bps) and Balanced Partitioning for Compression Optimization (bpc). Though we emphasize that the underlying implementation, outlined in Algorithm 1, is identical.

The former optimization, bps, is applied for hot functions in the binary that are executed during app start-up. The latter optimization, bpc, is applied for all the remaining cold functions. In our experiments, we record around $15\%$ of functions being hot. That allows us to reorder most of the functions in a “compression-friendly” manner, while at the same time improving the overall start-up performance. Compared to the prior work (Lee et al., 2022a), we improve the compressed size by up to $2\%$ and the start-up time by up to $5\%$, while speeding up the function layout phase by $20$x for SocialApp, one of the largest mobile apps in the world. We summarize the contributions of the paper as follows.

• •

  We formally define the function layout problem in the context of mobile applications. To this end, we identify and formalize two optimization objectives, based on the application start-up time and the compressed size.

• •

  Next we present the Balanced Partitioning algorithm, which takes as input a bipartite graph between function and utility vertices, and outputs an order of the function vertices. We also show how to reduce the aforementioned objectives of bpc and bps to an instance for the balanced partitioning.

• •

  Finally, we extensively evaluate the compressed size, the start-up performance, and the build time of the new algorithms with two large commercial iOS applications, SocialApp and ChatApp. Furthermore, we experiment with app size on Android native binaries, AndroidNative.

The rest of the paper is organized as follows. Section 2 builds an optimization model for compression and start-up performance, respectively. Then Section 3 introduces the recursive balanced graph partitioning algorithm that is the basis to effectively solve the two optimization problems. Next, in Section 4, we describe our implementation of the technique in an open source compiler, LLVM. Section 5 shows an experimental evaluation with real-world mobile applications. We conclude the paper with a discussion of related works in Section 6 and propose possible future directions in Section 7.

As explained in Section 1.1, the compression ratio of a Lempel-Ziv-based algorithm can be improved if similar functions are placed nearby in the binary. This observation is based on earlier theoretical studies (Raskhodnikova et al., 2013) and has been verified empirically (Ferragina and Manzini, 2010; Lin et al., 2014) in the context of lossless data compression. The works define (sometimes, implicitly) a proxy metric that correlates an order of functions with the compression achieved by an LZ scheme. Suppose we are given some data to compress, e.g., a sequence of bytes representing the instructions in a binary. Define a k-mer to be a contiguous substring in the data of length $k$, which is a small constant. Let $w$ be the size of the sliding window utilized by the compression algorithm; typically, $w$ is much smaller than the length of the data. Then the compression ratio achieved by an LZ-based data compression algorithm is dictated by the number of distinct k-mers in the data within each sliding window of size $w$. In other words, the compressed size of the data is minimized when each k-mer is present in as few windows of size $w$ as possible.

To verify the intuition, we computed and plotted the number of distinct $8$-mers within $64$KB-windows on a collection of functions from SocialApp and ChatApp; see Figure 3. To get one data point for the plot, we fixed a certain layout of functions in the binary and extracted its .text section to a string, by concatenating their instructions. Then for every (contiguous) substring of length $w$, we count the number of distinct k-mers in the substring; this number is the proxy metric predicting the compressed size of the data. Next we apply a compression algorithm for the entire array and measure the compressed size. To get multiple points on Figure 3, we repeat the process by starting with a different function layout, which is produced from the original one by randomly permuting some of its functions. The results in Figure 3 indicate a high correlation between the actual compression ratio achieved on the data and the predicted value based on k-mers. We record a Pearson correlation coefficient of $\rho>0.95$ between the two quantities. In fact, the high correlation is observed for various values of $k$ (in our evaluation, $4\leq k\leq 12$), different window sizes ($4$KB $\leq k\leq$ $128$KB), and various compression tools. In particular, we experimented with ZSTD (which combines a dictionary-matching stage with a fast entropy-coding stage), LZ4 (which belongs to the LZ77 family of byte-oriented compression schemes), and LZMA (a variant of a dictionary compression and as a part of the xz tool).

Given the high predictive power of the simple proxy metric, we suggest to layout functions in a binary so as to optimize the metric, as it can be easily extracted and computed from the data. To this end, we represent each function, $f\in F$, as a sequence of instructions. For every instruction in the binary, that occurs in at least two functions, we create a utility vertex $u\in U$. The bipartite graph, $G=(F\cup U,E)$ contains an edge $(f,u)\in E$ if function $f$ contains instruction $u$; refer to Figure 4 for an illustration of the process. The goal is to order $F$ so that instructions appear in as few windows as possible. Equivalently, the goal is to co-locate functions that share many utility vertices, so that the compression algorithm is able to efficiently encode the corresponding instructions.

In order to optimize the performance of the cold start, we develop the following simplified memory model. First, we assume that when a mobile application starts, none of its code is present in the main memory. Thus, the executed code needs to be fetched from the disk to the main memory. The disk-memory transfer happens at the granularity of memory pages, whose size is typically larger than the size of a function. Second, we assume that when a page is fetched, it is never evicted from the memory. That is, when a function is executed for the first time, its page should be in the memory; otherwise we get a page fault, which incurs a start-up delay. Therefore, our goal is to find a layout of functions that results in as few page faults as possible, for a typical start-up scenario.

In this model, the start-up performance is affected only by the first execution of a function; all subsequent executions do not result in page faults. Hence, we record, for each function $f\in F$, the timestamp when it was first executed, and collect the sequence of functions ordered by the timestamps. Such sequence of functions is called the function trace. The traces list the functions participating in the cold start and may differ from each other depending on the user or the usage scenario of the application. Next we assume that we have a representative collection of traces, $S$.

Given an order of functions, we determine which memory page every function belongs to; to this end, we need the sizes of the functions and assume a certain size of a page. Then for every start-up trace, $\sigma\in S$, and an index $t\leq|\sigma|$, we define $p_{\sigma}(t)$ to be the number of page faults during the execution of the first $t$ functions in $\sigma$. Similarly, for a set of traces $S$, we define the evaluation curve as the average number of page faults for each $\sigma\in S$, that is, $p(t):=\sum_{\sigma\in S}p_{\sigma}(t)/|S|$.

To build an intuition, consider what happens when there is a single trace $\sigma\in S$ (or equivalently, when all traces are identical). Then the optimal layout is to use the order induced by $\sigma$, in which case the evaluation curve looks linear in $t$. In contrast, a random permutation of functions results in fetching most pages early in the execution and the corresponding evaluation curve looks like a step function. We refer the reader to Figure 5(b) for a concrete example of how different layouts lead to different evaluation curves. In practice, we have a diverse set of traces, and the goal is to create a function order whose evaluation curve is as flat as possible.

We remark that although all traces have the same length, the prefix of each trace that corresponds to the startup part of that execution may differ in length due to device- and user-specific diverging execution paths. Therefore, instead of optimizing the value of $p(t)$ for a particular value of $t$, we try to minimize the area under the curve $p(t)$. To achieve this, we select a discrete set of threshold values $t_{1},t_{2},\ldots t_{k}$, and and use the bipartite graph $G=(F\cup U,E)$ with utility vertices

and edge set

where $\sigma^{-1}(f)$ is the index of function $f$ in $\sigma$. That way, the algorithm tries to find an order of $F$ in which the first $t_{i}$ positions of every $\sigma\in S$ occur, as much as possible, consecutively.

While implementing Algorithm 1 in an open source compiler, we developed a few modifications improving certain aspects of the technique. In particular, we implement the algorithm in parallel manner and limit the depth of the recursion in order to reduce the running time. Next we enhance the procedures for the initial split of functions into two parts and for the way to perform swaps between the parts, which is beneficial for the quality of the identified solutions. Finally, we propose a sampling technique to reduce the space requirements of the algorithm.

Figure 7 shows an overview of our build pipeline. We collect thousands of raw profile data files from various uses and periodically run offline post-processing to produce a single optimization profile. During post-processing, bps finds the optimized order of hot functions that were profiled, which includes start-up as well as non-start-up functions. Our apps are built with link-time optimization (LTO or ThinLTO). At the end of LTO, bpc orders cold functions for highly compressed binary size. These two orders of functions are concatenated and passed to the linker which finalizes the function layout in the binary. Both bps and bpc share the same underlying implementation.

Although we could run bps and bpc as one optimization pass, we have two separate passes for the following reasons: (i) Performing bps and bpc at the end of LTO would require carrying large amounts of function traces through the build pipeline; (ii) It is more convenient to simulate the expected page faults for bps offline using function traces; (iii) Likewise, we can evaluate bpc, in separate, for compression without considering profile data.

As shown in Figure 7, we first merge the raw profiles into the optimization profile with instrumentation metadata during post-processing. For the block coverage and dynamic call graph data, we simply accumulate them into the optimization profile on the fly. However, in order to run bps, we retain function timestamps from each raw profile. We encode the sequence of indices (that is, function trace) to the functions that participate in the cold start-up, and append them to a separate section of the optimization profile.

The bps algorithm uses function traces with thresholds, described in Section 2.2, to set utility vertices, and produces an optimized order for start-up functions. Once bps is completed, the embedded function traces are no longer needed, and can be removed from the optimization profile. Third-party library functions, and outlined functions that appear later than instrumentation in the compilation pass, might not be instrumented. To order such functions, we first check if their call sites are profiled using block coverage data. If that is the case, they inherit the order of their first caller. For instance, if an uninstrumented outlined function, $f_{outlined}$, is called from the profiled functions, $f_{A}$ and $f_{B}$, and bps orders $f_{A}$ followed by $f_{B}$, then we insert $f_{outlined}$ after $f_{A}$; this results in the layout $f_{A},f_{outlined},f_{B}$.

We run bpc without intermediate representation (IR), after optimization and code generation are finished, as shown in Figure 7. Although one could run the pass utilizing IR with (Full)LTO, our approach supports ThinLTO operating on subsets of modules in parallel. During code generation, each function publishes a set of hashes that represent its contents, which are meaningful across modules. We use one $64$-bit stable hash (Lee et al., 2022a) per instruction by combining hashes of its opcode and operands. That way, every instruction is converted to a $8$-mer, that is, a substring of length $8$. While computing stable hashes, we omit hashes of pointers and instead utilize hashes of the contents of their targets. Unlike outliners that need to match sequences of instructions, we neither consider the order of hashes, nor the duplicates of hashes. We only track the set of unique stable hashes, per function, as the input to bpc.

Since hot functions are already ordered, we filter out those functions before running bpc. Notice that outliners may optimistically produce many identical functions (Lee et al., 2022a), which will be folded later by the linker. To efficiently model the deduplication, bpc groups functions that have identical sets of hashes, and runs with the set of unique functions that are cold.

As a result of bps and bpc, all functions are ordered. We directly pass these orders to the linker during the LTO pipeline, and the linker enforces the layout of functions. To avoid name conflicts for local symbols, our build pipeline uses unique naming for internal symbols. This way, we achieve a smaller compressed app for faster downloads, while launching the app faster.

We evaluated our approach on two commercial iOS applications and one commercial Android application; refer to Table 1 for basic properties of the apps. SocialApp is one of the largest mobile applications in the world. The app, whose total size is over $250$MB, provides a variety of usage scenarios, which makes it an attractive target for compiler optimizations. ChatApp is a medium sized mobile app whose total size is over $50$MB. AndroidNative consists of around $400$ shared natives binaries. Unlike the two iOS binaries that are built with ThinLTO, each Android native binary is relatively small, and hence, can be compiled with (Full)LTO without significant increase in the build time. Since there is no fully automated MIP pipeline for building AndroidNative, we use the app only to evaluate the compressed binary size.

The experiments presented in this section were conducted on a Linux-based server with a dual-node 28-core 2.4 GHz Intel Xeon E5-2680 (Broadwell) having $256$GB RAM. The algorithms are implemented on top of release_14 of LLVM.

Here we present the impact of function layout on start-up performance. The new algorithm, which we refer to as bps, is compared with the following alternatives:

• •

  baseline is the original ordering functions dictated by the compiler; the function layout follows the order of object files that are passed into the linker;

• •

  random is a result of randomly permuting the hot functions;

• •

  order-avg is a natural heuristic for ordering hot functions suggested in (Lee et al., 2022a) based on the average timestamp of a function during start-up computed across all traces.

To evaluate the impact results of function layout in a production environment, we switched between using the current order-avg algorithm and the new bps algorithm for two different release versions, release $N$ and release $N+1$, and recorded the number of page faults during start-up. Table 2 presents the detailed results for the number of page faults on average and $99\%$ of millions of samples published in production. The experiment is designed this way, as in the production environment for iOS apps, we can ship only a single binary and we cannot regress the performance by utilizing less effective algorithms (e.g., baseline or random). We acknowledge that the improvements might come as a result of multiple optimizations, simultaneously shipped with bps. To account for this, we repeated the alternations three times in consecutive releases, and recorded the overall reduction in page faults. On average, bps reduced the number of major page faults by $6.9\%$ and $16.9\%$ for SocialApp and ChatApp, respectively. The improvement translates into $4.2\%$ (average) and $2.9\%$ (p99) reductions of the cold start-up time for SocialApp.

Table 3 shows a similar evaluation of the start-up performance with different function layouts on a particular device, $iPhone12~{}Pro$, during the first $10$s of the cold start-up. We repeat the experiment three times and calculated the mean number of page faults in (i) the .text segment and (ii) the entire binary, which additionally includes other data segments. Overall, bps reduces the total major page faults in the binary by $6.8\%$ and $18.3\%$ for SocialApp and ChatApp, respectively, while order-avg reduces them by $3.2\%$ and $15.9\%$, respectively. As expected, random significantly increases the page faults, negatively impacting the start-up performance.

One interesting observation from Tables 2 and 3 is that function layout has a bigger impact on the start-up performance of ChatApp than that of SocialApp. Our explanation is that SocialApp consists of dozens of native binaries and four of them participate in the start-up execution, which causes extra page faults while dynamically loading the binaries due to rebase or rebind. In contrast, ChatApp consists of only a few native binaries and only one large binary is responsible for the start-up; thus, an optimized function layout can directly impact the performance.

Next we investigate the start-up performance using a model developed in Section 2.2. Figure 8(a) illustrates the mean number of page faults simulated during start-up with up to $20$K time steps, utilizing different function layout algorithms, on SocialApp. As expected, random immediately suffers from many page faults early in the execution, as the randomized placement of functions likely spans many pages. Interestingly, baseline outperforms random; this is likely due to the natural co-location of related functions in the source code. Then, order-avg improves the evaluation curve over baseline, and bps stretches the curve even closer to the linear line, further minimizing the expected number of page faults.

Figure 8(b) shows the average number of page faults for a different number of function traces on SocialApp. Ideally, we want to build a function layout utilizing as few traces as possible. In practice, the start-up scenarios are fairly consistent across different usages, and one can reduce the need of capturing all raw function traces. We observe that running bps with more than $300$ traces does not improve the page faults on our dataset. As described in Section 3.1, we use the value by default for bps to reduce the space complexity of post-processing.

We now present the results of size optimizations on the selected applications. In addition to the baseline and random function layout algorithms, we compare bpc with the following heuristic:

• •

  greedy is a greedy approach for ordering cold functions discussed in (Lee et al., 2022a). It is a procedure that iteratively builds an order by appending one function at a time. On each step, the most recently placed function is compared (based on the instructions) with not yet selected functions, and the one with the highest similarity score is appended to the order. To avoid an expensive ${\mathcal{O}}(n^{2})$-computation of the scores, a number of pruning rules is applied to reduce the set of candidates; we refer to (Lee et al., 2022a) for details.

Table 4 summarizes the app size reduction from each function layout algorithm, where the improvements are computed on top of baseline (that is, the original order of functions generated by the compiler). The compressed size reduction is measured in three modes: the size of the .text section of the binary directly impacted by our optimization, the size of the executables excluding resource files such as images and videos, and the total app size in a compressed package. We observe that bpc reduces the size of .text by $3\%$ and $1.8\%$ for SocialApp and ChatApp, respectively. Since this section is the largest in the binary (responsible for $2/3$ of the compressed ipa size), this translates into overall $1.9\%$ and $1.3\%$ improvements. At the same time, the impact of all the tested algorithm on the uncompressed size of a binary is minimal (within $0.1\%$), which is mainly due to differences in code alignment. We stress that while the absolute savings may feel insignificant, this is a result of applying a single compiler optimization on top of the heavily tuned state-of-the-art techniques; the gains are comparable to those reported by other recent works in the area (Lee et al., 2022a, b; Rocha et al., 2022; Damásio et al., 2021; Liu et al., 2022).

An interesting observation is the behavior of random on the dataset, which worsen the compression ratios by around $5\%$ in comparison to the baseline layout. Again the explanation is that similar functions are naturally clustered in the source code. For example, functions within the same object file tend to have many local calls, which makes the corresponding call instructions good candidates for a compact LZ-based encoding. Yet bpc is able to significantly improve the instruction locality by reordering functions across different object files.

Additionally, we evaluate the compressed size reduction for AndroidNative. Notice that the total app size is measured on Android package kit (apk) which includes not only native binaries, but also Android Dex bytecode. Unlike the aforementioned two iOS apps, the .text size of the native binaries is only $1/4$ of the total app size. Therefore, the overall app compressed size win is smaller than for the .text or the executable sections. We observe that these compressed sizes for AndroidNative are more sensitive to different layouts. This is because AndroidNative is a traditional C/C++ binary, where the number of blocks per function is substantially larger than those of the iOS apps, as illustrated in Table 1. Function call instructions encode their call targets with relative offsets whose values differ for each call-site. Unlike the iOS apps written in Objective-C having many dynamic calls, AndroidNative has fewer call-sites, making it more compression-sensitive.

The new Algorithm 1 has a number of parameters that can affect its quality and performance. In the following we discuss some of the parameters and explain our choice of their default values.

As discussed in Section 3, the central component of the algorithm is the objective to optimize at a bisection step, which we refer to as the cost of a partition the set of functions into two disjoint parts. Equation 1 provides a general form of the objective, where the summation is taken over the utility vertices. For a given utility vertex having $L(u)$ functions adjacent in one part and $R(u)$ functions adjacent in another part, $cost\big{(}L(u),R(u)\big{)}$ can be an arbitrary objective that is minimized when $L(u)=0$ or $R(u)=0$ and maximized when $L(u)=R(u)$. Besides to the uniform log-gap defined by Equation 2, we consider two alternatives. The first one is probabilistic fanout defined as follows:

where $p\in[0,1]$ is a constant. The objective is motivated by partitioning graphs in the context of database sharding (Kabiljo et al., 2017), where $p$ represents the probability that a query to a database accesses a certain shard. The second utilized objective represents the absolute difference between $L(u)$ and $R(u)$:

It is easy to verify that both objectives satisfy the requirements mentioned above.

The plots on Figure 9 illustrate the impact of the optimization objective on the quality of resulting function layouts, that is, the corresponding compressed size and the (estimated) number of page faults during start-up. For the fanout objective, we utilize $p=0.9$, as it typically results in the best outcomes in the evaluation. We observe that the uniform log-gap cost results in the smallest binaries, outperforming fanout and absolute difference by $1.7\%$ and $2.3\%$, respectively. Similarly, this objective is the best choice for start-up optimization, where it yields fewer page faults by $4.1\%$ and $11.5\%$ on average, respectively. Thus, we consider the uniform log-gap as the preferred option for the optimization. However, function orders produced by the algorithm coupled with the other two objectives are still meaningfully better than alternatives investigated in Sections 5.2 and 5.3.

Next we experiment with two parameters affecting Algorithm 1: the number of refinement iterations and the maximum depth of the recursion. Figure 9 (top) illustrates the impact of the latter on the quality of the result evaluated on ChatApp. For every $0\leq d<20$ (that is, when the input graph is split into $2^{d}$ parts), we stop the algorithm and measure the quality of the order respecting the computed partition. It turns out that bisecting vertices is beneficial only when $F$ contains a few tens of vertices. Therefore, we limit the depth of the recursion by $\min(\lceil\log_{2}n\rceil,16)$ levels. To investigate the effect of the maximum number of refinement iterations, we apply the algorithm with various values in the range between $1$ and $45$; see Figure 9 (bottom). We observe an improvement of the quality up to iteration $20$, which serves as the default limit in our implementation.

Finally, we explore the choice of the initial splitting strategy of $F$ into $F_{1}$ and $F_{2}$ in Algorithm 1. Arguably the initialization procedure might affect the quality of the final order, as it provides the starting point for the subsequent local search optimization. To verify the hypothesis, we implemented three initialization techniques that bisect a given graph: (i) a random splitting as outlined in the pseudocode, (ii) a similarity-based minwise hashing (Chierichetti et al., 2009; Dhulipala et al., 2016), and (iii) an input-based strategy that splits the functions based on their relative order in the compiler. In the experiments we found no consistent winner among the three options. Therefore, we recommend the simplest approach (i) in the implementation.

We now discuss the impact of function layout on the build time of the applications. The time overhead by running bpc is minimal: it takes less than $20$ seconds on the larger SocialApp and close to $1$ second on the smaller ChatApp. In contrast, greedy results in a noticeable slowdown, increasing the overall build of SocialApp by around $10-15$ minutes, which accounts for more than $10\%$ of the total build time, which is around $100$ minutes.

The worst-case time complexity of our implementation is upper bounded by ${\mathcal{O}}(m\log n+n\log^{2}n)$, where $n$ is the total number of functions and $m$ is the number of function-utility edges. The estimation aligns with Figure 10(a), which plots the dependency of the runtime on the number of functions in the binary. We emphasize that the measurements are done in a multi-threaded environment in which distinct subgraphs (arising from the recursive computation) are processed in parallel. In order to assess the speed up of the parallelism, we limit the number of threads for the computation; see Figure 10(b). Observe that using two threads provides approximately $2$x speedup, whereas four threads yields a $2.5$x speedup in comparison with the single-threaded implementation. Increasing the number of threads beyond that does not yield measurable runtime improvements. However it is likely that for larger instances with more recursive subgraphs, utilizing multiple threads can be beneficial.