The current way local search operators look up for neighboring solutions is a bit naive in that we exhaustively check all options for routes / pairs of routes. Obviously relocating a job in another route at a rank where tasks are very far away does not make sense. In that case we stop early without any validity check because the gain itself is not interesting. Yet probably a lot of time is actually spent evaluating gain for silly moves.

I recall toying with more advanced filtering in the early days of the implementation, e.g. only trying a relocate move to the nearest routes or ranks in routes. From what I recall, it did have a detering impact on quality (some interesting moves missed in the process) and the computing gain was not that relevant because the overall approach was "fast enough" as a first implementation.

Now I think would be a good time to evaluate the speedups we could get from this idea. The question is whether we'll be able to easily find the sweet spot between unnecessary evaluation and missed moves. Either we can come up with some threshold where we'll only miss a marginal number of moves, either we can maybe make this configurable to some extent.