MGMLaboratory
Back

Menu

01Home
02About Us
03Projects
04Publications
05Member
06Articles
07Contact

Let's Talk

Open in Mail app

Socials

Malang (ID) --:--Privacy PolicyTerms of Service

April 5, 20182 min read

Dijkstra or A star? What the timings actually sayDijkstra or A star? What the timings actually say

On a small campus road network the heuristic search wins clearly on a single route, and loses most of that edge as the destination moves farther away.

  • Journal
  • Publications

Written by

  • SRShirasaka RenIT & Infrastructure · Student Member

In this article

  1. 01The gap depends on distance
  2. 02Where the plain algorithm still earns a place

The usual summary is that A star beats Dijkstra and you should just use it. Timings from an Android navigation prototype put a condition on that advice. The gap between the two algorithms is real, but it depends on how far the route has to travel.

The measurements come from a prototype running on a Google Nexus 6 with Android 7.0, working over a campus road network of 134 nodes and 154 edges. Queries were grouped by how close the start and end points were, which is what makes the result interesting.

A handheld GPS unit. Short routes leave a search little room to prune. Photo: Voschix, CC0.
Fig. 01A handheld GPS unit. Short routes leave a search little room to prune. Photo: Voschix, CC0.

01/02

The gap depends on distance

  • Nearby nodes: A star finished in about 0.10 ms, against an average of 1.22 ms for Dijkstra overall.
  • Nodes on opposite sides of the network: A star took about 1.16 ms, close to the plain algorithm.
  • Heuristic overhead: estimating distance with the Euclidean formula added roughly 0.26 ms per query.

The pattern follows from how the heuristic works. A star gains when the estimate can steer the search away from large parts of the graph. Over a short distance there is not much to steer away from, and the estimation cost takes a bigger share of the total.

02/02

Where the plain algorithm still earns a place

Dijkstra solves a different problem. It finds the shortest path from one source to every other node in a single pass, so its work carries over when an app needs several destinations from the same origin. The authors suggest pre-caching routes with Dijkstra when the next destination can be predicted, and reserving the guided search for one off requests.

Roads, signs and daily travel. Route data is fetched as JSON and cached locally. Photo: LondekaT, CC BY-SA 4.0.
Fig. 02Roads, signs and daily travel. Route data is fetched as JSON and cached locally. Photo: LondekaT, CC BY-SA 4.0.

The honest conclusion for a working app is that neither number is uncomfortable on a graph this size. Both algorithms answer in milliseconds on hardware from a few years back. Where the difference starts to matter is at scale, or when an app fires many queries in a row.

There is also a design lesson that has little to do with either algorithm. The framework keeps road data on the device after the first fetch, so a route can be computed without waiting on the network. For how fast the app feels to use, that choice does more work than any milliseconds saved inside the search loop.

Source

  1. Pinandito, A., Kharisma, A.P., Perdana, R.S. (2018). Framework Design for Map-Based Navigation in Google Android Platform. Journal of Telecommunication, Electronic and Computer Engineering (JTEC), 10(1-8).

Next articleSwapping pathfinding algorithms without rewriting the app(Keep scrolling)(Read it next)(Loading)