Alternative routes extremely slow on self-hosted instance (27s @ 86 km, >115s @ 730 km) - Core/LM preprocessing has no effect

openrouteservice
1

Hi all,

I’m running a self-hosted ORS v9.9 instance (driving-car, edge-based CH, graph covering DE+AT+CZ, ~2 GB graph, 16 GB heap) and single-route requests are excellent — a 730 km Berlin->Salzburg route returns in ~42 ms. However, alternative_routes requests are unusably slow, and I can’t find a way to speed them up.

Measured timings (same instance, target_count: 3, share_factor: 0.6, weight_factor: 1.6):

  • 86 km route: single route ~80 ms, 3 alternatives ~27 s
  • 730 km route: single route ~42 ms, 3 alternatives >115 s (did not complete in my test window)

What I’ve already tried, based on older forum threads suggesting landmark-based speedups:

  1. Built a dedicated LM graph (methods.lm.enabled: true, landmarks: 16). No measurable improvement for alternatives.
  2. Built a dedicated Core graph (methods.core.enabled: true, landmarks: 32, with execution.methods.core.active_landmarks: 6). The graph builds fine and single routes work, but alternative-route timings are identical to the plain CH graph — no speedup at all.

My current understanding is that alternative_routes generation is an inherently expensive Dijkstra-style search that does not benefit from CH, Core, or LM preprocessing, since these accelerate point-to-point queries but not the penalty-based plateau/admissible-path exploration used for alternatives. Is that correct?

My questions:

  1. Is there any supported configuration that makes alternative_routes viable on medium/long distances (200–700 km), or is the algorithm fundamentally unsuited to long routes?
  2. Does target_count dominate the cost, i.e. would target_count: 2 (one alternative) be dramatically cheaper than 3, or is the bulk of the cost in the initial admissible-path search regardless of count?
  3. Do share_factor / weight_factor materially affect runtime, or only which results are returned?
  4. Is there a recommended distance ceiling above which alternatives should simply be disabled?

For context: my use case is an EV charging route planner, where alternatives are only a “nice to have” for the web UI. My current plan is to disable alternatives entirely for ORS and keep the single fast optimal route, falling back to a commercial provider (which returns alternatives natively in <1 s) only when alternatives are explicitly needed. But I’d prefer a native ORS solution if one exists.

Config and version details available on request.

Thanks!

Jan

2

Hi Jan,

You are right, alternative routes is based on Dikstra’s algorithm, so LM, Core and CH are not relevant for it.

ORS uses bidirectional Dijkstra for computing alternative routes, which can get quite slow for long distances. In your example of 700km it needs to inspect all nodes in a distance of 350km around the start and the destination to find the best path. Afterwards it continues the search to find alternatives. Therefore, the larger `target count` is, the slower is the search usually. I have no data on how expensive this is, this would best be evaluated on your setup.

Also, the alternative routes feature is rather a proof of concept in ORS. The quality of the alternatives may vary a lot.

Best regards,
Sascha