You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* JGraphT version: 1.5.2
* Java version (java -version)/platform: 17.0.6
Issue
The current BFSShortestPath implementation of getPath simply calls getPaths and then retrieves the desired path from the SingleSourcePaths. This causes the BFS algorithm to calculate the shortest path to all other (reachable) vertices in the graph, regardless of whether we have already found the shortest path to the desired sink.
For very large graphs this causes a significant overhead, especially if the sink is close to the source. Imagine a graph like:
A -> B -> (huge subgraph)
Using the BFSShortestPath to find the shortest path from A to B would continue to traverse the entire subgraph after B.
Steps to reproduce (small coding example)
vargraph = newSimpleDirectedGraph<Integer, DefaultEdge>(DefaultEdge.class);
graph.addVertex(1);
graph.addVertex(2);
graph.addVertex(3);
graph.addEdge(1, 2);
graph.addEdge(2, 3);
varalg = newBFSShortestPath<>(graph);
varresult = alg.getPath(1, 2); // also calculates the shortest path from 1 to 3 (1 -> 2 -> 3), even though we already found 2
Expected behaviour BFSShortestPath#getPath should terminate as soon as the shortest path from source to sink was found.
Other information
E.g. DijkstraShortestPath#getPath has an implementation that terminates early as soon as the shortest path to the sink vertex was found.
The text was updated successfully, but these errors were encountered:
Issue
The current
BFSShortestPath
implementation ofgetPath
simply callsgetPaths
and then retrieves the desired path from theSingleSourcePaths
. This causes the BFS algorithm to calculate the shortest path to all other (reachable) vertices in the graph, regardless of whether we have already found the shortest path to the desired sink.For very large graphs this causes a significant overhead, especially if the sink is close to the source. Imagine a graph like:
Using the
BFSShortestPath
to find the shortest path fromA
toB
would continue to traverse the entire subgraph afterB
.Steps to reproduce (small coding example)
Expected behaviour
BFSShortestPath#getPath
should terminate as soon as the shortest path from source to sink was found.Other information
E.g.
DijkstraShortestPath#getPath
has an implementation that terminates early as soon as the shortest path to the sink vertex was found.The text was updated successfully, but these errors were encountered: