Repository navigation
edit tool: levenshtein allocates full matrix on every call #47604
Description
Description
levenshtein() in src/tool/edit.ts allocates a full (n+1)×(m+1) matrix on every call. BlockAnchorReplacer calls it per-line during fuzzy matching, so this creates unnecessary GC pressure on large files. Also, the per-file locks Map (line 35) never evicts entries — every edited filepath stays in memory forever, which is a slow memory leak in long-running sessions.
Plugins
None
OpenCode version
Latest dev branch (337fd14)
Steps to reproduce
1.Open a long-running opencode session
2.Use the edit tool on many different files (the locks Map grows without bound)
3.For the levenshtein issue: use the edit tool with a fuzzy oldString on a large file — BlockAnchorReplacer runs levenshtein per-line, each allocating a full matrix
Screenshot and/or share link
N/A — this is a code-level perf issue, not a UI bug
Operating System
Linux (Ubuntu)
Terminal
N/A — not terminal-specific
Activity
perf(tool/edit): use rolling rows instead of full matrix in levenshtein
neriousy commentedon Oct 20, 2026
Thanks for the report. The current v2 edit implementation no longer uses the reported Levenshtein matcher, and its file locks are removed when no holders or waiters remain, so I'm closing this as resolved.