Rust Extensions Impact on Write Performance

[zprobst]

Hello 👋

I am the maintainer of nodestream which is a declarative framework for Building and Maintaining graph data. As a result, a core workflow that nodestream integrates with neo4j is ETL-ing data into the graph. I ran an experiment with nodestream's neo4j connector to see if there was any appreciable benefit from ingestion.

NOTE: It's very likely this isnt actually an issue in the code (which is why this is a disucssion), but I think it may be worth noting this in the README.

Experimental Design

Using nodestream, I ingested two datasets:

• One node for each of the numbers in the range of [0,100000). We use this test internally to see a general latency added by a database connector. Roughly described by this pipeline.
• A data set representing a movie data / recommendation graph following the guide defined here.

Results

Pipeline	Neo4J Driver	Average Time (10 Iterations)
Numbers	Python	11 Seconds
Numbers	Rust Extensions	10 Seconds
Movies	Python	25 Seconds
Movies	Rust Extensions	20 Seconds

From these it appears that the rust extensions can provide a 10ish percent to 20ish percent improvement. I expected that write performance gains would not be as high as read performance gains. The note in the readme makes note that the biggest benefits are on reading few records with large amounts of data. These tests present almost the exact opposite of that. Writing data with many records and essentially no data back out.

Hopefully this is a useful data point for the maintainers and potential users.

[robsdedude]

Thanks for taking the time to note only evaluate the extensions but also share you findings. In the worst case scenario I've found, the extensions make no notable difference. Therefore, I'm updating the README to say

The exact speedup depends on the use-case but has been measured to be up to 10x faster.

The way the extensions currently work is that they replace the packstream encoding and decoding part of the driver. In every DBMS interaction, there's some of it going on, but the optimization potential can easily be dwarfed by other factors like network latency, Query execution times, driver state management, etc. Further, since those parts of the driver need to have the capability to access and create Python objects as well as call back into Python land, there's no sensible time to release the GIL, which means multi-threaded performance is not going to benefit more than single-threaded performance.

All these things are implementation details and in the future we might decide look into more optimization potential, which might or might not include shifting the border of what parts of the driver the extensions cover.