Repository navigation
Use a table for TSPTW travel times - #271
Merged
Merged
Conversation
The matrix element posted one index over all n*n customer pairs per position, and its propagator rebuilds its support lists in every clone. A* and CABS clone and propagate every child near the root, so this dominated their runtime. Use one shared TupleSet over (x[i-1], x[i], c[i]) instead, and note the per-node cost and unkeyed dominance in the heuristic guidance documentation.
zayenz
force-pushed
the
feature/tsptw-tupleset
branch
from
October 30, 2026 09:07
af7e5b1 to
84e20b6
Compare
zayenz
marked this pull request as ready for review
October 30, 2026 09:09
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The TSPTW example ran very slowly under the experimental A* and CABS engines: on a generated 60-node instance CABS explored about 100 nodes/s, while BAB managed about 80,000.
Root cause
The engines are fine; the problem is the model. The travel time constraint
element(d, x[i], n, x[i-1], n, c[i])is posted as an index-pair variable over all n² pairs plus anElement::Intover the flattened matrix. Its clone constructor drops the index/value lists, so the first propagation in every clone rebuilds and sorts them. Fixing one customer removes a value from every otherx[j]through the channel, which wakes all ~n of these propagators and makes each rescan ~n² entries. A* and CABS clone and propagate every child of every node they expand near the root, so they pay this cost on every node, while BAB mostly works deep in the tree where domains are small. At n=60, CABS spent 2.97 s of a 3 s run instatus()on children at depth 1–6, against 17 ms spent cloning.Change
examples/tsptw.cpp: replace the matrix element with oneTupleSetover (x[i-1], x[i], c[i]), shared by all positions, and post it withextensional.gecode/search.hh: document inHeuristicGuidancethat a node costs a clone plus propagation at shallow depth, so models should use propagators that stay cheap there. Also document that without adominance_key, every node offered to the beam is compared with every node in it.No engine changes.
Measurements
Built-in instances, complete search, median of 20 runs (
-mode time -samples 20), RelWithDebInfo:Generated instances with n customers, nodes explored in 3 s. These were measured with a local file-reader hack that is not part of this PR:
Validation
-DGECODE_ENABLE_EXPERIMENTAL=ON, next to a build oforigin/main.gecode-test -test ^Search: 25815 passed, 0 failed.git diff --checkis clean.