-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance Issues when using Grand #54
Comments
this may be linked to #52 |
Almost certainly you're right that this is delay caused by multidigraph conversion So I guess that's a trick question — yes that's expected right now, but definitely broken behavior and bad and we must fix it :) While we work on that, it's possible that commenting out that line that checks and converts may be a good short-term solution... Also this graph may be of a reasonable size to simply run in-memory rather than with the SQL backend... Would be happy to chat more about this to make sure we have a working solution for your needs right away!! |
Running |
Wow thank you @davidmezzetti for jumping in with a workaround, and thank you @jackboyla for the great fix in #55! This fix is now live on PyPI and can be installed with Amazing team! @chilicrabcakes give it a whirl and see if this fixes your performance issue? |
Awesome! I'll try the new fix, let you all know how it goes |
Hey guys - great library first of all.
I'm creating a graph using the grand library and saving as an SQLite backend. I want to query the graph using Cypher, so I installed GrandCypher and am running the code like this:
Then I'm creating a GrandCypher object like this:
However, this step is taking more than half an hour to complete. My graph has 13090 nodes and 19253 edges. Is this expected?
I'm able to run networkx functions normally, like G.nx.nodes() and G.nx.edges() for example.
The text was updated successfully, but these errors were encountered: