## 6 Simulation Results
### Simulation Results  
In Figures 4 and 5, we compare the effect of cost constraints on the delay values and running time. Similar to [10], we generate a DAG for the structure of the real world, that is, the Gaussian elimination (GE) algorithm [44], and the dimension of the given graph is 4. For each task, the total number of mobile devices and edge servers corresponding to the service is cached as [2; 3]. Since the time complexity of OOS is identical to that of BFF, and its performance is inferior, while the brute force algorithm yields the same results as BFF but with significantly longer running times, we exclude OOS and the brute force algorithm from the comparison based on running time. As the cost constraint increases, the delay values of the offloading solutions generated by various algorithms progressively decrease. When the cost constraint is very small, the solutions obtained by OOS perform the worst. This is due to the high server cost, which causes all feasible solutions to violate the cost constraint. As a result, the algorithm is forced to spend a considerable amount of time performing local caching in order to execute the tasks. On the other hand, both TUL and Hermes consistently achieve a \((1+\epsilon)\)-approximation solution. As the cost constraint is relaxed, the runningtimes of these algorithms decrease. However, the running time of TUL is significantly smaller than that of Hermes. In contrast, BFF computes all possible solutions based on the DT table for each experiment and then selects the optimal solution that satisfies the cost constraint. As a result, the running time of BFF does not change as the cost constraint is relaxed. In all cases, the solutions obtained by BFF are identical to the optimal solution. When the cost constraint is very small, the running time of BFF is slightly smaller than that of Hermes. Although the time complexity of BFF is theoretically exponential, in practical applications, the number of labels retained during each task iteration tends to be relatively small, making the algorithm more efficient in real-world scenarios. Figures 6 and 7 describe the effect of task size on delay values and running time when the cost constraint is set to a tiny value. The task mapping is derived from a randomly generated DAG diagram. For each task, the total number of mobile devices and edge servers corresponding to the service is cached as [2; 3]. Due to the long running time of the brute force algorithm and the fact that its results are identical to those of BFF, it is not included in this experiment. Given that the time complexity of OOS matches that of BFF, but its empirical performance is inferior, we exclude OOS from the running time comparison. As the number of tasks grows, the delay values of the offloading solutions derived from different algorithms generally increase. Among them, OOS consistently shows the poorest performance, with the highest delay values across all task sets. On the other hand, FixDoc demonstrates the fastest running time as it solely utilizes DP to compute the minimum completion cost of task offloading. However, the solutions it provides result in relatively high delay values. Both TUL and Hermes are able to consistently provide a \((1+\epsilon)\)-approximation solution, regardless of the task set being used. However, TUL stands out by achieving this with a significantly smaller running time compared to Hermes, which makes TUL more efficient in terms of execution speed. In contrast, BFF produces solutions with the lowest delay values, indicating that it optimizes delay performance better than the other algorithms. Its running time is obviously smaller than that of Hermes when the  
Figure 4: Effect of cost on delay. Figure 5: Effect of cost on running time. task quantity is low, but as the task set continues to grow, the difference in running time between it and TUL becomes increasingly large. Figures 8 and 9 provide a detailed illustration of how the approximation ratio \(\epsilon\) influences the performance of the TUL algorithm.