ruvnet / ruvnet/RuVector

ruvector-mincut: LocalKCut::check_cut does an O(m) edge scan per call

Open
#963 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
4.5k
Forks
603
Avg merge
23h 32m
Merged PRs (30d)
59

Description

Found during the 2026-09-05 PR-review mission while reviewing #941 (agent pr-review-ruview-ruvector; the PR itself is being closed as its own verdict was REJECT and it collides with main's ADR-340).

Observed: crates/ruvector-mincut/src/localkcut/mod.rs:368LocalKCut::check_cut scans every edge (O(m)) on each call, so the local k-cut check is not local in cost; repeated checks during repair scale with total graph size rather than the cut's neighbourhood.

Ask: bound the scan to the incident edges of the candidate cut (adjacency-indexed), or document the cost and cap the call count in the repair loop. A benchmark that grows m while holding the cut size fixed would show the current behaviour.

Not established: whether any production path calls check_cut in a loop today; the finding is from reading the function.

🤖 Generated with RuFlo

https://claude.ai/code/session_019xHM4rAH4aaShb4DTr1n6s

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in crates/ruvector-mincut/src/localkcut/mod.rs at LocalKCut::check_cut around line 368, and trace its callers in the repair loop to establish whether repeated checks occur. Add a benchmark that grows m while keeping the candidate cut size fixed. Done means the scan cost is bounded to incident edges, or the existing cost and repair-call limit are explicitly documented and enforced.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.