Before you start to multithread, make sure your algoritms are working properly and efficiently with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases.

You probably want A*, specially if you have an easy way to estimate distance left to goal, dijkstra's is useful if you can't.

Before you start to multithread, make sure your algoritms are working properly and efficiently with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases.
DFS more of a learning example of an extremely simple algorithm, that should very seldom be used for real problem solving.

You probably want A*, specially if you have an easy way to estimate distance left to goal, dijkstra's is useful if you can't.

Before you start to multithread, make sure your algoritms are working properly and efficiently with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases.
DFS more of a learning example of an extremely simple algorithm, that should very seldom be used for real problem solving.

You probably want A*, specially if you have an easy way to estimate distance left to goal, djikstra's is useful if you can't.

Before you start to multithread, make sure your algoritms are working properly with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases.
DFS more of a learning example of an extremely simple algorithm, that should very seldom be used for real problem solving.

You probably want A*, specially if you have an easy way to estimate distance left to goal, djikstra's is useful if you can't.

Before you start to multithread, make sure your algoritms are working properly with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases.

Before you start to multithread, make sure your algoritms are working properly with extensive tests.

Then reduce the times it is run, why would it be needed to run at a fixed timestep?
Only times the path changes is if the goal changes or the terrain changes.

Then you can simplify the terrain to have less nodes to search.

DFS is not "supposed to be faster", only in very special cases, I don't know where you got that from.