Add implicit max tasks values

[jcoupey]

Issue

Fixes #648

Tasks

• Derive upper bound on number of jobs for vehicles based on capacity constraints
• Derive upper bound on number of jobs for vehicles based on timing constraints
• Benchmark
• Update CHANGELOG.md
• review

[jcoupey]

A couple results comparing this PR to current master.

Usual CVRP benchmarks

On the usual CVRP benchmarks, average computing time (ms) reported in the table below show a steady reduction around -10% across various exploration levels.

x	aa3a1ee	3f255b9	delta (%)
0	447	406	-9.2
1	1601	1417	-11.5
2	3630	3212	-11.5
3	6391	5641	-11.7
4	12332	10945	-11.2
5	19551	17452	-10.7

The average reduction in applied operators is ~5% but this is highly dependent on the instance. If route sizes are close to the bound we use, we expect to see a higher impact.

Digging a bit into the details, most of the computing times reductions are slight but a few are drastic.For example the total number of operators applied for X-n655-k131 at x=5 goes from 2420184384 down to 379628064 (-84%) and the computing time goes from 39.9s down to 19.3s (-52%).

Usual VRPTW benchmarks

On the Solomon/Homberger instances, the reduction in number of operators applied is much smaller, probably because the number of tasks in a route is much less constraining than other parameters like TW restrictions.

On average, I'm seeing a -1.2% computing time reduction so much less than on pure-CVRP instances.

Custom instances

I generated a few random instances with typical obvious max_tasks restrictions. I'm seeing a significant impact on those, of course depending on the setup and whether actual routes sizes are close to the bounds we derive. In general I have the same impression as with above benchmarks that pure CVRP instances are much more impacted than VRPTW ones that have no strong capacity constraints.

Example of a huge instance where load balancing is done with all vehicles capacity set to [23] while all jobs have "delivery": [1] and no pickup. Implicit max_tasks value is 23.

Solutions are identical but solving time goes from 97.3 s down to 35.0 s (a 2.8x speedup).

Diffing the operator logs shows that all operators changing route sizes are affected. The number of tested operators has been divided by more than 6 overall.

4,8c4,8
< MixedExchange,765971627,37
< TwoOpt,400954601,740
< ReverseTwoOpt,801909202,305
< Relocate,710053703,220
< OrOpt,399399470,98
---
> MixedExchange,30263589,37
> TwoOpt,23827245,740
> ReverseTwoOpt,46045064,305
> Relocate,30832775,220
> OrOpt,11339188,98
16c16
< Total,3498399756,13929
---
> Total,562419014,13929

[jcoupey]

We're not there yet as I'm actually seeing an increase of computing times for most VRPTW benchmarks and real-life instances. After some digging I found out that the (small) solving gain we get by cutting down on operators is overtaken by the loading time required to actually compute the bounds.

The timing-based bounds currently require going through all pair of jobs for each vehicle to account for lower bounds on travel time to/from. This happens in O(V*J^2) and there is no way around that since travel times are vehicle dependent.

If we drop the travel time part in the bound and only rely on setup + service times, then we can pre-process all job-related stuff and we'd be down to O(V*J) for this part, just like the capacity-based bounds.

I think we can definitely leave with a looser bound not accounting for travel times since:

• this means we should only see computing time improvements;
• min values for travel times used in the previous bound are usually very small anyway in a "dense" scenario.