Improving SQLGraph _get_neighbors performance

[JoOkuma]

Trying to address #221

cc @yfukai

[yfukai]

Thanks! I was thinking about using recursive cte, but let me check if this already solves the issue!

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.40%. Comparing base (06b4588) to head (f098332).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #222      +/-   ##
==========================================
+ Coverage   88.35%   88.40%   +0.05%     
==========================================
  Files          54       54              
  Lines        3856     3856              
  Branches      665      665              
==========================================
+ Hits         3407     3409       +2     
+ Misses        268      266       -2     
  Partials      181      181              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JoOkuma]

Hi @yfukai, you're fast :)

I changed a few other things to try to improve the _get_degree performance.

[JoOkuma]

I was not familiar with "recursive CTE"; it might be a good alternative on top of this.

[yfukai]

It's a kind of recursive retrieval of the rows. I just learned it from ChatGPT...

[yfukai]

Unfortunately the bottleneck seems to be somewhere extra. I'll try the recursive CTE!

[yfukai]

Hi @JoOkuma, my benchmark was wrong! It seems that your update fasten the code x50 times. I also tried the recursive CTE but that only accelerated the code *1.1 times from this branch. I think this is great and we don't need to further complicate the code. Thank you for this update!

[JoOkuma]

Awesome!

@yfukai, I'll merge this PR.

This operation should be as fast as SQLGraph.filter(<YOUR NODE SEEDS>).subgraph(node_attr_keys=[]), it would be interesting to time how long this function takes for your graph.

If ...filter(...).subgraph(...) is faster, we could implement it using this and get the tracklets using rustworkx or numba.