Skip to content
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

Potential Performance Improvements #127

Open
kkaris opened this issue Jan 4, 2023 · 1 comment
Open

Potential Performance Improvements #127

kkaris opened this issue Jan 4, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@kkaris
Copy link
Collaborator

kkaris commented Jan 4, 2023

The neo4j python documentation have a page with performance recommendations, some of which are worth a try.

The ones that look relevant for us are:

Specify the target database on all queries when creating a new session:

driver.session(database="<DB NAME>")

Status: will not implement (some queries ran faster, but most queries actually ran slower with specifying the database by a small margin)

Use query parameters instead of hardcoding or concatenating values into queries:

session.run("MATCH (p:Person {name: $name}) RETURN p", name="Alice")

Status: proposed in #129, however, the speedup was not very big and not all queries tested actually became faster although the queries with speedup were in the majority.
Status: added in #129

Always use node labels:

session.run("MATCH (p:Person|Animal {name: $name}) RETURN p", name="Alice")

Use multithreading (or async if we upgrade to 5.x) to run concurrent sub-queries on a complex query e.g. get_stmts_for_stmt_hashes and queries depending on it.

@kkaris kkaris added the enhancement New feature or request label Jan 4, 2023
@bgyori
Copy link
Member

bgyori commented Jan 4, 2023

These are pretty good, I think doing the first one is trivial since session creation is done in a single place. The second one should also be straightforward, we just need to modify the low-level Cypher queries to be constructed this way instead of string manipulation. As for node labels, I think we are already doing that whenever possible. The last one could also be interesting, you could try it out on get_stmts_for_stmt_hashes to see if it makes a difference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants