Add UndirectedGraph and DirectedGraph data structures
#7460
Conversation
These can be used to represent the existing modules graph in the `PackageGraph` module, or a new linkage graph concept, which would help with breaking dependency cycles for certain packages.
MaxDesiatov
added
no functional change
MaxDesiatov
changed the title
LinkageGraph and DirectedGraph data structuresUndirectedGraph and DirectedGraph data structures
|
@swift-ci test |
|
@swift-ci test |
|
@swift-ci test windows |
| /// edge exists. | ||
| /// | ||
| /// See https://en.wikipedia.org/wiki/Adjacency_matrix for more details. | ||
| struct AdjacencyMatrix { |
There was a problem hiding this comment.
Why the difference in adjacency list vs matrix between the directed and undirected graphs?
There was a problem hiding this comment.
I started with an adjacency list in a directed graph implementation, but then proceeded to an undirected graph where adjacency matrix seemed obviously more performant when adding edges: just flipping two bits in the matrix instead of adding potential array (re-)allocations with the list.
I'll add benchmarks to get a confirmation for that. I'm unsure though if either is a clear win in all cases, adjacency matrix may be fast at adding edges, but not the fastest for different kinds of graphs analysis and lookups. Keeping both implementations for now for future reference seemed like a sensible idea given that it's an NFC PR anyway.
There was a problem hiding this comment.
I'm unsure though if either is a clear win in all cases
Yeah, really depends on what type of graphs we have and what the main operation on them is. If they're sparse (which I would assume is the case) and we mainly want to loop over edges (rather than check if there is an edge), lists are likely better. Happy for you to keep both for now if you want.
…7460) `DirectedGraph` can be used to represent the existing modules graph in the `PackageGraph` module hopefully with better performance due to reduced number of allocations. `UndirectedGraph` could represent a new linkage graph concept, which would help with breaking dependency cycles for certain packages with products that don't have a linkage cycle. I started with an adjacency list in a directed graph implementation, but then proceeded to an undirected graph where adjacency matrix seemed obviously more performant when adding edges: just flipping two bits in the matrix instead of adding potential array (re-)allocations with the list. I'm unsure though if either is a clear win in all cases, adjacency matrix may be fast at adding edges, but not the fastest for different kinds of graphs analysis and lookups. Keeping both implementations for future reference.
…7460) `DirectedGraph` can be used to represent the existing modules graph in the `PackageGraph` module hopefully with better performance due to reduced number of allocations. `UndirectedGraph` could represent a new linkage graph concept, which would help with breaking dependency cycles for certain packages with products that don't have a linkage cycle. I started with an adjacency list in a directed graph implementation, but then proceeded to an undirected graph where adjacency matrix seemed obviously more performant when adding edges: just flipping two bits in the matrix instead of adding potential array (re-)allocations with the list. I'm unsure though if either is a clear win in all cases, adjacency matrix may be fast at adding edges, but not the fastest for different kinds of graphs analysis and lookups. Keeping both implementations for future reference.
DirectedGraphcan be used to represent the existing modules graph in thePackageGraphmodule hopefully with better performance due to reduced number of allocations.UndirectedGraphcould represent a new linkage graph concept, which would help with breaking dependency cycles for certain packages with products that don't have a linkage cycle.