perf(inline-suggest): debounce and cancel completion refilter while typing#1727
perf(inline-suggest): debounce and cancel completion refilter while typing#1727desperadoxhy wants to merge 1 commit into
Conversation
|
Thank you for your contribution! Before we can merge this PR, you need to sign our Contributor License Agreement. To sign, please comment below with:
I have read the CLA Document and I hereby sign the CLA. xuhengyu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. |
|
I have read the CLA Document and I hereby sign the CLA. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3fd9eac658
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| let ranked = await Task.detached(priority: .userInitiated) { | ||
| provider.filterAndRank(fullItems, prefix: prefix, context: sqlContext) | ||
| }.value |
There was a problem hiding this comment.
When a user types with pauses just over the 30 ms debounce and the candidate set is large, cancelling cursorRefilterTask no longer cancels work that has reached this detached child; the child continues running filterAndRank to completion while the cancelled parent awaits .value. That lets stale-prefix refilters pile up as background CPU work, so the refilter path is not actually cancelable and can still hurt editor responsiveness under the load this change is meant to address.
Useful? React with 👍 / 👎.
1 participant
问题
补全窗口开启时，每次光标移动(即每次按键)同步在主线程跑
filterAndRank(三次模糊匹配 + 排序，候选 200+ 列时很重)，不经过防抖、不可取消。连打时主线程卡顿。方案
CodeEdit 的
completionOnCursorMove协议强制同步返回，无法真正异步。改用：同步filterByPrefix快速路径(只过滤不排序)保响应，后台 30ms 防抖 + 可取消的 Task 重算完整排序结果缓存，下次按键命中缓存。连打时增量 narrowing 让候选快速收敛。代价：完整排序结果最早下次按键才显示，但远好于卡主线程。验证
SQLCompletionProviderConcurrencyTests守护filterAndRank的纯函数性与并发安全(把计算移到后台 Task 的前提)