networkx
Revert "Cache edges, degree, adj properties of Graph classes (#5614)"
This reverts commit f50fc70b8cb6b4f5217a6d5505ba0e2b82b4761b and https://github.com/networkx/networkx/commit/d46c0c219f6082424074f077ef2c1e40a9ff7065
This change brought in a performance regression in core classes. I'm not a 100% sure if we should keep this change (cacheing) in 3.0 or not?
If we want to revert, this can also go into 2.8.5
For the slowdown in G.copy the benchmark copies an empty graph. The slowdown goes away if the graph has some edges. I think this is due to the changed lines: if hasattr(self, "adj"): del self["adj"]. And since the new graph being created doesn't have an "adj" attribute in its __dict__, we are slowing down graph creation by one hasattr. But I'd like to test that more to make sure. If we remove the property for adj, we will remove these issues, and speed up just as the cached property was supposed to. But it will slow down graph creation in favor of faster edge lookup/reporting. I'll try to test the speed differences between those.
For the graph_create test, the DiGraph was slowed down, but not the other classes. I don't see how that could be happening. Did something strange happen with just the DiGraph test? It is true that DiGraph has to check 3 attributes (adj, pred, succ) but so does MultiDiGraph... Similarly for to_directed and to_undirected. Some of the graph classes show slowdown and others don't. Are these results repeatable?
Finally, a minor nit, but could the horizontal axis of these graphs be changed from date/time of the commit? Replacing it with a commit index would make the data equally spaced horizontally and perhaps make the slopes a better indicator of impact of each commit.
Would it be possible to rerun the benchmarks on PR #5836 ? I'm not sure how involved that is. I ran some timing tests locally and it seemed to fix the problem for the methods I tested.
If that PR does resolve the speed regressions we could leave the cached_property in place.