## 5 Experiments
### Results in the m-Principal-u-Assistant Scenario
#### 5.3.2 Computational Performance  
There are three concrete scenarios, including the 3-principal-2-assistant scenario, the 3-principal-3-assistant scenario, and the 4-principal-2-assistant scenario. The results are shown in Figure 6.  
In the 3-principal-2-assistant scenario, as shown in Figure 6a,c, GL, IP-L, IP-I, and IP-D share similar numbers of served vertices, but GI serves far less vertices than they do. The GL, GI, IP-L, and IP-D cost time less than 40 seconds, even if \(n=20\), but the IP-I costs more time, and exceeds 800 seconds when \(n=20\). The running time of IP-I is too large to be employed in larger graphs. Figure 6b,d shows the algorithm performances in the larger graphs, the size of which ranges from 30 to 100. Except when \(n=30\), the IP-D serves the most vertices. The gap between the number of vertices served by the IP-D and the others grows larger as the sizes of graphs grow larger. With respect to the running time, the IP-D costs the most time among all the algorithms, but its maximum running time is less than 600 s. In the 3-principal-3-assistant scenario shown in Figure 6e-h, and the 4-principal-2-assistant scenario shown in Figure 6i-l, the IP-D has a similar performance. As a whole, the number of vertices served by the IP-D is the largest among all the algorithms, and the running time of the IP-D is the largest among the others but is reasonable in practice.  
There is a strange phenomenon where IP-L and IP-D expend more time when \(n=30\) than \(n=100\). The main time cost comes from the integer programming, which is \(\mathcal{NP}\)-hard. More columns in the integer programming indicate a longer CPU time. Based on the experimental data, when the number of columns that denote the principal-assistant routes in the paper reaches 400, the IP-L and IP-D will expend more time to solve their integer programming problems. Because the \(d_{0}\) is twice the diameter of the graph, when \(n=30\), one principal-assistant route cannot serve many tasks surrounding the initial vertex, so the new route r, which serves more unserved tasks far from the initial vertex, can be added to \(\Omega^{\prime}\). However, when \(n=100\), the \(d_{0}\) is very large and the principal-assistant routes seek to serve the vertices surrounding the initial vertex; many generated routes are the same or cannot coexist, and the actual size of the route set \(\Omega^{\prime}\) when \(n=100\) is less than the size when \(n=30\).  
Figure 5: The performance of our approach and baseline algorithms in the \(1\)-principal-1-assistant scenario. Test of the Number of Served Vertices: (**a**); Test of the Running Time: (**b**,**c**).  
In general, the number of vertices served by the IP-D is largest among all the algorithms, although the running time of the IP-D is also largest among them; however, this is reasonable in practice.  
Figure 6: The performance of our approach and baseline algorithms in the \(m\)-principal-\(u\)-assistant scenario. Test of the Number of Served Vertices in the 3-principal-2-assistant scenario: (**a,b**); Test of the Running Time in the 3-principal-2-assistant scenario: (**c,d**); Test of the Number of Served Vertices in the 3-principal-3-assistant scenario: (**e,f**); Test of the Running Time in the 3-principal-3-assistant scenario: (**g,h**); Test of the Number of Served Vertices in the 4-principal-2-assistant scenario: (**i,j**); Test of the Running Time in the 4-principal-2-assistant scenario: (**k,l**).