Skip to content

Use capacity bounds for LS operator pruning#710

Merged
jcoupey merged 19 commits intomasterfrom
enhancement/LS-capacity-pruning
May 18, 2022
Merged

Use capacity bounds for LS operator pruning#710
jcoupey merged 19 commits intomasterfrom
enhancement/LS-capacity-pruning

Conversation

@jcoupey
Copy link
Collaborator

@jcoupey jcoupey commented May 12, 2022

Issue

Fixes #709.

Tasks

  • Expose delivery/pickup sums across jobs for all routes
  • Prune Relocate moves
  • Prune OrOpt moves
  • Prune CrossExchange moves
  • Prune MixedExchange moves
  • Prune TwoOpt moves
  • Prune ReverseTwoOpt moves
  • Prune RouteExchange moves
  • Prune SwapStar moves
  • Prune UnassignedExchange moves
  • Benchmark
  • Update CHANGELOG.md
  • review

@jcoupey
Copy link
Collaborator Author

jcoupey commented May 18, 2022

Here are some comparisons on the usual benchmark classes. The best candidates to make a difference are the CVRP instances, but VRPTW instances are impacted too as they also have capacity constraints, albeit less binding.

Solution quality

This PR gets the exact same solution as current master as we only abort early for some operators based on new bounds derived from capacity constraints and route loads.

Average computing times

CVRP

Average computing time for all instances in each benchmark class across various exploration levels.

Bench master at 990565b PR at 5203bac delta (%)
CVRP x=0 444 230 -48.2
CVRP x=1 1523 749 -50.8
CVRP x=2 3550 1720 -51.5
CVRP x=3 6264 3055 -51.2
CVRP x=4 12200 5942 -51.3
CVRP x=5 19557 9604 -50.9

That's another 2x speedup (on top of the recent improvements in other PR). The gain is especially high since those instances have strong capacity limitations applying.

VRPTW

Average computing time reported for all instances in each benchmark class using -x 5.

Bench master at 990565b PR at 5203bac delta (%)
Solomon 380 401 +5.5
Homberger 200 1827 1617 -11.5
Homberger 400 9345 7852 -16.0
Homberger 600 23628 19338 -18.2
Homberger 800 46046 37766 -18.0

On the smallest instances, the tests overhead actually cover the gain of early aborts, but the speedup then increases with bigger instances. The impact here is smaller since capacity constraints are less predominant that timing constraints in those instances, but that's still good to have! Again this is an additional gain on top of #696 that already drastically reduced computing time on those instances.

@jcoupey jcoupey merged commit c238bf6 into master May 18, 2022
@jcoupey jcoupey deleted the enhancement/LS-capacity-pruning branch May 18, 2022 12:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Prune local search moves based on capacity constraints

2 participants