## 5 Computational Experiments  
The RDIS has been implemented in C++ and compiled via the Visual C++ compiler on a PC with 2.2 GHz speed. Before testing the algorithm on the benchmark instances, the parameters of the construction and large neighborhood components have been set. With respect to the construction component, the algorithm has two parameters, namely NRepeats and SwapProb, indicating the frequency and the probability of performing swap moves in the RJP method. Based on the preliminary experiments, we observed that setting NRepeats and SwapProb to 1 and 0.4, respectively, yields the best results by providing a balance between the quality and diversity of the initial solutions generated by the construction component. With respect to the large neighborhood component, the RDIS has also two parameters, namely ChunkSize, and SweepRatio. Setting ChunkSize to a small value (\(\leq\)5) will increase the speed of the procedure at the expense of lower solution quality. On the other hand, setting ChunkSize to any value larger than 10 will dramatically increase the running time. Moreover, the computational experiments show that setting the value of SweepRatio close to 1 or 0 degrades the performance. Due to these observations, and based on further preliminary experiments, ChunkSize and SweepRatio have been set to 7 and 0.3, respectively. We have employed [PERSON]'s repository of benchmark instances [42], available on the website supported by the University of Applied Sciences of Western Switzerland, to test the performance of the RDIS. In this repository, as many as 120 instances exist, and all of these instances have been extracted for the RDIS to be tested on. These instances are in 12 classes, with 10 instances existing in each class. The number of jobs and machines of these instances are in the range 20-500 and 5-20, respectively. Before presenting the performance of the stochastic algorithm on the benchmark instances and comparing the results with the best available solutions in the literature, we present the internal operations and convergence of the algorithm in solving the instances _ta001_, and _ta012_. Figure 7 shows solution value versus iteration for 5000 iterations, for the instance _ta001_. As is seen, a high-quality solution can follow a low-quality one, and vice versa. Figure 7: Solution value versus iteration in the benchmark instance _ta001_. In general, the quality of the best solution obtained improves as the number of iterations increases. Figure 8a shows how this has happened in the first 100 iterations of the _ta001_ problem instance. As is seen, before iteration 20, the quality of the best-obtained solution has improved from 1413 to 1336 and for the next 60 iterations, no improvement has occurred. Between iterations 80 and 100, two other improvements have occurred and 1336 has improved to 1297. A similar trend can be seen in other instances as well; Figure 8b shows the convergence pattern, in just over 2000 iterations for a larger problem instance, _ta012_. SAOP, PACO, M-MMAS, ILS and HGA_RMA are all run on a CPU with 2.6 GHz clock speed and the results are reported in [48]. However, RAMP and NEGAVNS are run on a 2.2 GHz and a 2.4 GHz CPU respectively, and PSOVNS is run on a 2.8 GHz CPU. Furthermore, CPU clock speeds are presented in Table 2 and a scaling factor has been calculated. However, since CPU times depend on many factors such as developer skills, compiler efficiency, implementation details, and CPU architecture, any running time comparison should be made with caution.