We are facing similar troubles in our cases. Our problem usually have 1 warehouse and around 1000 jobs. At beginnig we got solving time run up to 24h, sometimes it can get several hours to get just initial solution. Of cource we implement several PrematureTerminationListeners because of it. So we now have static 5 min for iteration phase. But initial solution cannot be premature terminated. So even this didn’t help. But there was interesting break through month ago. I found out, that THREAD_COUNT is big player in calculation time and even InsertionStrategy can have recognisable impact on searching initial solution. First, threads, we’ve solved this problem with dynamic calculation based on vehicle count. Based on fact found on this forum “If you have only one vehicle, then multiple thread can slow computation” and “each route is calculated on one thread”, this is true and I presume that you do not need more threads then vechile count in your problem. With one vehicle, thus one route, we use only one thread and get initial time down by 50%. Second change we made was to replace RegretInsertion with BestInsertion, maybe its not that smart, but solution from BestInsertion are more or less good and calculation is faster. So for large problems we switch to BestInsertion. The third bottleneck are constraints. So far I believe asumption, that Activity constraints have recognisable impact on computation time, so try to optimise thouse constraints a lot. After these changes we got our initial time for our problem 1000+ jobs - 1 vehicle - 1 warehouse around half hour, before it goes up to 20 hours. I recommend using VariationCoefficientTermination aside with other premature termination mechanics. It helps a lot for simpler problem to terminate iteration when solution cannot get better significantly. The last rule we have to implement on bussiness level was “Try to avoid useing more warehouses than 1”.
Hope this helps someone to speed up!