Remove The Hashmap from Shorted Path for Centrality Computation #1307
Conversation
Pull Request Test Coverage Report for Build 11846697683Details
💛 - Coveralls |
There was a problem hiding this comment.
I think minimizing the number of hashing operations that happen during the shortest path is a good idea in general. But I am not convinced this works, we need to benchmark this more carefully.
I have a feeling this method will be slower for directed graphs, where some nodes are not able to reach all other nodes in the graph. In those cases, having a small hashmap with the nodes that can be reached is much faster than having a large vector with mostly non-visited entries.
| let mut verts_sorted_by_distance: Vec<G::NodeId> = Vec::with_capacity(c); // a stack | ||
| let mut predecessors: Vec<Vec<usize>> = vec![Vec::new(); max_index]; | ||
| let mut sigma: Vec<f64> = vec![0.; max_index]; | ||
| let mut distance: Vec<i64> = vec![-1; max_index]; |
There was a problem hiding this comment.
A more appropriate type here is Option<i64> if you want to represent missing paths. I'd even say Option<usize>
rustworkx-core/src/centrality.rs
Outdated
| let coeff = (1.0 + delta[iw]) / path_calc.sigma[iw]; | ||
| let p_w = path_calc.predecessors.get(iw).unwrap(); | ||
| for iv in p_w { | ||
| //let iv = graph.to_index(*v); |
|
|
||
| for node in graph.node_identifiers() { | ||
| predecessors.insert(node, Vec::new()); | ||
| sigma.insert(node, 0.0); | ||
| distance.insert(node, -1); | ||
| } |
There was a problem hiding this comment.
Se how the hashmap was full filled with value for all node of the graph, so replacing with a vec of size of node bound will no be a problem for cache efficiency, because hashmap was already full when the algorithm started
I heard your argument and i agree that we should benchmark to be sure that it will be faster when the hashmap was not full filled |
Hello,
I removed the hashmap for the shorted path for centrality.
This may improve performance.
Tell me what do u think about :)