# Enabling Horizontal Collaboration in Logistics Through Secure Multi-Party Computation
## 4 Toward an MPC-Based Solution for the CFDP
### Implementation and Evaluation
#### 4.4.2 Efficiency Analysis  
For benchmarking and better comparison with the plaintext variant, we re-used the reference map defined by [PERSON] et al. [3], and ran the solver on problem instances with an increasing number of orders (10, 50, 100, 500 and 1000) and of trucks (from 5, 50, and 500) defined in a publicly available reference dataset for the CFDP ([[https://github.com/nrike6](https://github.com/nrike6)]([https://github.com/nrike6](https://github.com/nrike6)) 7/CollaborativeFreightDeliveryProblem-Benchmark (accessed on 30 June 2025)).  
The solution was executed on a virtual machine equipped with a single-core CPU at 2.8 GHz, and with 16 GiB of RAM, running Ubuntu 24.04 and Python 3.10. The results of the experiment are reported in Figure 2. There, a log-log plot was chosen because both axes span multiple orders of magnitude, and smaller values would otherwise be difficult to distinguish on a linear scale. For each choice of number of orders and of trucks, 10 experiments were run, and we report the median running time, although we remark that the variation was very small, with a standard deviation of less than 2% of the mean figures (and almost always less than 1%).  
Figure 2: Scalability results for 10, 50, 100, 500, and 1000 orders (note the log-log plot).  
The longest running time is obtained with 1000 orders and 50 trucks, totaling 25,002 s, i.e., slightly less than 7 h. However, when the number of trucks increases, the complexity is actually lowered, reaching 13,990 s, i.e., less than 4 h (note here the log-scale on the \(y\)-axis). This is due to a combination of inherent MPC problems and the current design of our solution: on one hand, the running time of the MPC sub-routine fill_truck is a constant, independent of the number of trucks that it actually fills, something inherent to MPC protocols; this means that the total running time of our solution is higher when fill_truck is executed many times, regardless of how many trucks are filled in each execution. On the other hand, a problem instance with a lower number of trucks will necessitate to create an empty truck drive earlier, since it is less likely that sufficiently many trucks are available at the order positions; since our current solution creates a single empty truck drive at a time, this leads to frequent executions of the fill_truck sub-routine. The connecting line in Figure 2 corresponds to a measured polynomial relationship of the running time with respect to the number of orders, ranging from an approximate power of 3 for 50 trucks, to an increase which is slightly above linear for 500 trucks. While a formal analysis of the projected running time for larger instances would be beyond the scope of this paper (cf. also the discussion on the limited gains for large instances as discussed in Section 3.3), we remark that these experiments indicate that instances with, for example, 10,000 orders, could be processed in reasonable time, if enough many trucks are available.  
Future work could modify the solution in order to create a higher number of empty truck drives in a single batch; however, given our current purpose of a feasibility study, we are primarily interested in the order of magnitude of the running time, to first ascertain whether the approach is feasible at all. Our experiments show a running time of some hours for thousands of orders and dozens of trucks, and we hence deem it a suitable basis for further improvements and optimization.