Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use cost bound in heuristic #1222

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

jcoupey
Copy link
Collaborator

@jcoupey jcoupey commented Feb 11, 2025

Issue

Fixes #1219

Tasks

  • Store and update relevant data to compute the bound
  • Avoid going through whole route for rank-based insertion tests based on bound
  • Same but for pickup and delivery
  • Try ordering unassigned jobs to increase bound efficiency
  • Update CHANGELOG.md
  • review

@jcoupey
Copy link
Collaborator Author

jcoupey commented Mar 11, 2025

My attempts at ordering unassigned jobs to favor cutting branches were void: we'd need to maintain an extra data structure + pay the re-ordering price from time to time, which in my tests destroys the benefit of using the bound with unsorted data.

@jcoupey
Copy link
Collaborator Author

jcoupey commented Mar 11, 2025

Benchmarking setup for job-based instances

Instances

In order to measure the impact of this PR, I've generated random instances with sizes ranging from 200 to 5000 jobs. Since route length is a major factor in complexity, I've generated several instances per number of jobs to match typical sizes: S (10 jobs per route), M (50 jobs per route), L (100 jobs per route), XL (250 jobs per route) and XXL (500 jobs per route).

Process

For all those instances I'm solving only with the heuristics (no local search) with both current master at 9905815 and PR at 31476a7. We're interested in the solving time ratio.

Results

Solving speedup between master and PR depending on instance and route sizes.

Jobs S M L XL XXL
200 1.50 1.71 1.58  
500 1.43 2.09 1.87 1.64
1000 1.86 1.73 1.82 1.71 1.69
2000 1.68 2.65 2.36 2.31 1.86
3000 1.92 2.99 2.61 2.68 1.84
4000 1.93 3.02 2.53 2.59 1.88
5000 2.04 3.25 3.04 2.48 2.02

If we look at total computing time, the speedup is 2.17, meaning PR is more than 2x faster than master. Again that is only on heuristic time, which may be a small part of overall computing time is many situations.

@jcoupey
Copy link
Collaborator Author

jcoupey commented Mar 11, 2025

Benchmarking setup for shipment-based instances

Using the usual Li&Lim benchmark (all classes with instance sizes from 100 to 1000), again solving only with the heuristics (no local search) with both current master at 9905815 and PR at 31476a7.

Average computing times (ms) and speedup

  9905815 31476a7 Speedup
100 5 4 1.25
200 25 21 1.19
400 109 85 1.28
600 291 201 1.45
800 599 372 1.61
1000 984 581 1.69

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.

Heuristics speed-up
1 participant