Skip to content

Conversation

@misterhat
Copy link

@misterhat misterhat commented Jan 4, 2020

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.

const EasyStar = require('easystarjs');               
                                                      
const easystar = new EasyStar.js();                   
const grid = require('./obstacles.json') ;            
grid[1162][938] = 0;                                  
easystar.setGrid(grid);                               
easystar.setAcceptableTiles([0]);
easystar.setIterationsPerCalculation(500);            
easystar.setParallelLimit(-1); // 1, 2, etc.

for (let i = 0; i < 5; i += 1) {                      
    console.time(`long-path-${i}`);                   
    easystar.findPath(1380, 1318, 368, 982, () => {   
        console.timeEnd(`long-path-${i}`);            
    });                                               
}                                                     

for (let i = 0; i < 50; i += 1) {                     
    console.time(`short-path-${i}`);
    easystar.findPath(1380, 1318, 1360, 1324, () => {
        console.timeEnd(`short-path-${i}`);
    });
}

const calculate = () => {                             
    easystar.calculate();                             
    setTimeout(calculate, 5);                         
};                                                    
calculate();

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.

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.
Copy link
Owner

@prettymuchbryce prettymuchbryce left a 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
@misterhat
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants