Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

android

a-star

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.java

The size of the map is large, dimensions around 8000x8000, when I use the A star Pathfinder.java to calculate the route from one to another point in the map.

The A star Pathfinder calculate 1 by 1 and used in the large map (8000x8000), the performance/calculation speed is quite low/slow (not efficient). I have tried to increase the calculation to 100 by 100, it work fine but the route path drawn is not smooth in curve.

Is there anyway to improve the route calculation performance with the A star algorithm or any other sugguest to solve the issue? I need help to solve the issue.

like image 817
FrancisOrb Avatar asked Mar 14 '23 12:03

FrancisOrb


1 Answers

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
like image 164
Austin Avatar answered Apr 30 '23 14:04

Austin