You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The LocalSearch::try_job_additions function is used to try adding unassigned jobs during the local search phase. It happens after any route change that may give room to new insertions, or after loosening the solution, which we do once in a while when reaching a local minima.
Setting aside a couple tricks (handling shipments, shortcuts based on priorities), the current implementation sketch is as follows:
Go through all unassigned jobs, then through all routes, then all potential insertion ranks to find out the best overall (valid) option in term of cost increase.
Apply the best option.
Loop back to 1. while there are available insertion options.
We do need to compute the information of the best cost for all job/route pair with associated insertion rank, but we are basically running the whole process at step 1. for each new choice, while most of the previous information are still valid and could be stored. So when inserting job j in route for vehicle v, we should keep all data for other jobs/vehicles, but only recompute choices across remaining unassigned jobs and vehicle v.
Of course this would only make a small difference for instances with no unassigned jobs. However, the time spent in try_job_additions can amount to nearly 20% of the overall running time in a situation with many unassigned jobs, like in this flame graph.
The text was updated successfully, but these errors were encountered:
@krypt-n that would be great! I flagged this for the next release but did not have time to get started. We'll see how things go and whether to keep this for v1.9 or if it should be postponed.
Anyway feel free to ask if you need any additional pointers.
The
LocalSearch::try_job_additions
function is used to try adding unassigned jobs during the local search phase. It happens after any route change that may give room to new insertions, or after loosening the solution, which we do once in a while when reaching a local minima.Setting aside a couple tricks (handling shipments, shortcuts based on priorities), the current implementation sketch is as follows:
We do need to compute the information of the best cost for all job/route pair with associated insertion rank, but we are basically running the whole process at step 1. for each new choice, while most of the previous information are still valid and could be stored. So when inserting job
j
in route for vehiclev
, we should keep all data for other jobs/vehicles, but only recompute choices across remaining unassigned jobs and vehiclev
.Of course this would only make a small difference for instances with no unassigned jobs. However, the time spent in
try_job_additions
can amount to nearly 20% of the overall running time in a situation with many unassigned jobs, like in this flame graph.The text was updated successfully, but these errors were encountered: