-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parallel Paths #76
base: master
Are you sure you want to change the base?
Parallel Paths #76
Conversation
when many varying path lengths are used, distributes the path finding per iterationsPerCalculation on up to limit paths. when calculate() is called, switch to a solving a different path in the queue instead of solving them sequentially.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey misterhat. Thanks for this contribution. I think it's a nice idea for a feature.
I left a couple of comments. Let me know what you think about my API suggestion.
Would you mind writing a couple of tests as well?
* remove parallelLimit and replace it with binary parallel compute option * added unit tests for serial and parallel path computing
Ok I think this is what you asked for? I restored the original bin/* files from the master branch, changed the API + typescript bindings and added unit tests for serial and parallel pathfinding. |
add
.setParallelLimit(limit)
when many varying path lengths are used, distributes the path finding per iterationsPerCalculation on up to limit paths. when calculate() is called, switch to a solving a different path in the queue instead of solving them sequentially.
if the parallel limit is 1, easystar acts as it currently does by resolving each path in the order they were submitted. if it's set to 2, it will switch between two path finding instances every
.calculate()
call. if -1, switch the path finding instance every time.calculate()
is called.it still results in the same total amount of time to calculate the paths, but the load distribution could be useful.
e.g.
with setParallelLimit unset or set to 1, it resolves the long-paths first (at ~400ms each), then the short-paths after ~2 seconds. with setParallelLimit set to -1, it resolves the short-paths from 60-120ms and the long paths after ~2 seconds.
this is useful if you have small paths mixed with large paths, as the small paths can return much quicker even if they were added during the solving of a much larger and slower path.