Replies: 2 comments 2 replies
-
Thanks for this! Maybe we can just speed up Some quick benchmarks for a graph with 10,000 nodes. In [21]: %%time
...: _ = set(nx.common_neighbors(G, 1, 2))
...:
...:
CPU times: user 2.74 ms, sys: 3 µs, total: 2.74 ms
Wall time: 2.78 ms
In [22]: %%time
...: _ = set(nx.neighbors(G, 1)) & set(nx.neighbors(G, 2))
...:
...:
CPU times: user 515 µs, sys: 55 µs, total: 570 µs
Wall time: 575 µs
In [23]: %%time
...: _ = G._adj[1].keys() & G._adj[2].keys()
...:
...:
CPU times: user 202 µs, sys: 33 µs, total: 235 µs
Wall time: 240 µs |
Beta Was this translation helpful? Give feedback.
2 replies
-
#7244 is merged so this has hopefully been fully addressed - if there are further ideas for improvements, go ahead and open a new issue and link back to this one! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Some functions need to know the neighborhood overlap of 2 nodes.
For example
https://networkx.org/documentation/latest/_modules/networkx/algorithms/link_prediction.html#common_neighbor_centrality
or
https://networkx.org/documentation/latest/_modules/networkx/algorithms/link_prediction.html#jaccard_coefficient
In these examples it's implemented using
len(list(nx.common_neighbors(G, u, v)))
or
sum(1 for _ in nx.common_neighbors(G, u, v))
This is very slow however and makes the respective code basically unusable for the graphs I'm dealing with. One small change could easily fix this. Instead of getting the number of elements in a generator we could use set intersection:
I'd be happy to hear thoughts on this.
Beta Was this translation helpful? Give feedback.
All reactions