Open khoale88 opened 1 year ago
Ah β this is a good find β sorry that you bumped into this! I won't have time to address this until at least next week, but I will make this a top priority for the repo! Thank you for reporting it!! (And nice to see you over here on this repo too :) )
Well, my projects are big. The performance with sql backend appears to be one not-so-serious problem.
Is it a good idea to have separate classes for Graph and DiGraph just like nx has? I'm not sure about compatibility regarding other dialects though.
FYI, grandiso and grand-cypher are super useful but they also perform unwell if a graph has tens of thousands of nodes and connected edges. Sometimes, it's hundreds of times faster to iterate through the graph than using isomorphism. I think if grandiso can fail a candidate even earlier when it detects node/edge attribute mismatch, it would drastically improve. Maybe starting with proving the interestingness
.
I think splitting Graph/DiGraph makes sense (and KIND OF got started here); every library tends to have split representations between the two.
FYI, grandiso and grand-cypher are super useful but they also perform unwell if a graph has tens of thousands of nodes and connected edges. Sometimes, it's hundreds of times faster to iterate through the graph than using cypher/grandiso. I think if grandiso can terminate even earlier when it detects node/edge attribute mismatch, it would drastically improve.
π¬ yikes! sorry to hear that β what sorts of mismatches are you seeing that it's not breaking early from? grandiso DOES short-circuit a match when there's an attribute mismatch (code) but it's not perfect. Probably each consumer of grandiso β ESPECIALLY grandcypher β should reimplement its own is_node_attr_match
callable with shortcircuit smarts...
well, I'm not so good with graph theory. You are the master :D.
I think splitting Graph/DiGraph makes sense (and KIND OF got started here); every library tends to have split representations between the two.
not sure if I can work a bit on it this weekend. But as we do the split, it is a non-backward compatible change.
Probably each consumer of grandiso β ESPECIALLY grandcypher β should reimplement its own is_node_attr_match callable with shortcircuit smarts...
You are right, I improve by having another is_node_structual_match to handle DiGraph. It considers both in_degree and out_degree separately. The result is 55% faster!
Wow, that's a huge improvement!!!
btw @khoale88,
not sure if I can work a bit on it this weekend. But as we do the split, it is a non-backward compatible change.
I think we're still okay to make breaking changes like this since we're pre-v1.0 for now β happy to chat more about this if you have ideas on how to do this well :)
It has been a while... I can recall something by looking at my incomplete works 10 months ago.
BUT, there should be some unsolved challenges preventing me from finishing my work that I can't remember, unfortunately :(.
Hi @j6k4m8,
There is an issue with
grand.Graph
andgrand.dialects.NetworkXDialect
.Since NetworkXDialect is inherited from
networkx.Graph
, there happen to be discrepancies betweengrand.dialects.NetworkXDialect
andnetworkx.Digraph
which is popagated back to grand.Graph. One of them is thenetworkx.Graph.edges
returnsEdgeView
whilenetworkx.Digraph.edges
returnsOutEdgeView
.Below is one of the test to replicate the issue
The result is