Implement A star (A*) path algorithm in large map, low performance

Question

I\'m using this A star (A*) Pathfinder.java to calculate & generate my route in an Android map app. https://github.com/xSmallDeadGuyx/SimpleAStar/blob/master/Pathfinder.

Answer 1

Implementation: If you're looking for a code review, post the working code over at CodeReview.StackExchange.com. They can probably give you some optimization tips.

Algorithm: Here are several considerations from an algorithmic perspective.

First, take a look at your heuristic. If the heuristic estimates too low, A* degenerates to Dikstra's algorithm. If the heuristic estimates too high, A* degenerates to a Greedy Best First Search. A* with an admissible heuristic sits somewhere in the middle: it produces an optimal path, but maintaining optimality costs you additional computation time. If you are willing to sacrifice optimality, you may select a heuristic which sometimes over-estimates the distance to the goal. By doing so, the paths are not guaranteed to be optimal, but the greediness of the algorithm could reduce execution time.

Also, if the world is static (i.e. the layout is known a priori), you can pre-compute much information to help speed-up your search. Several algorithms exist to accomplish this task. Swamps is an approach that pre-computes regions that tend to be searched needlessly (i.e. the swamps). Unless travelling into or out of a swamp, the regions need not be searched at runtime. The speed-up attributed to Swamps depends heavily on the world's topography; more deceptive maps (i.e. ones that tend to lead the search toward swamps) have much to benefit.

Another approach is to use a hierarchical pathfinding approach such as HPA*. This could have significant performance increases on a map as large as yours (8000x8000, yikes). HPA* operates by grouping regions into linked local clusters and computing the cost for crossing cluster boundaries a priori. Then, the search proceeds in multiple levels: the high-level effort focuses the search by leveraging the pre-computed costs, and the low-level effort determines the exact path that will be used.

Also, algorithms exist to reduce the number of nodes explored by A* by exploiting characteristics of the environment at runtime. For instance, Jump Point Search (JPS) exploits the fact that grid graphs (like the one you're using) often exhibit symmetries. If movement in your world has constant cost, JPS can "skip over" many nodes in the search and reduce search times by a considerable amount. I've seen it reduce A* search time by 24x, others have seen over a 30x improvement.

One final note: From what I can tell, you're using L1 paths (i.e. 4-cardinal directions). You may have much to gain by preprocessing paths between waypoints and using a differential heuristic. See this article for a demo and the discussion of a JavaScript implementation here.

Additional links:

• Great visualizations of JPS in action
• More info for JPS
• Variations of A*
• Amit's A* Pages: the best A* resource I know
• How to speed up A* blog post