Idea: Coalesce cache scans for batched source removal
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
No source files, tests, or entry points are named. Begin by collecting a real branch-switch or folder-removal trace, then measure time to fresh diagnostics as requested; the work is justified only if it shows a noticeable stall and preserves mixed-event ordering.
索引モデルが issue の本文から書いたものです。
説明
Deferred idea
Removing a source file currently scans module ownership and the derived-query caches to discard affected entries. When one batch removes many warmed sources, those scans run again for every file. Consecutive removal-only events could be coalesced and retired together, so each cache is scanned only once. Any other event would first flush the pending removals, which keeps mixed-event ordering intact.
This is an idea to evaluate later, not a request to land the existing prototype.
Evidence so far
The benchmarks used real sources from the combined core+acme dependency closure: 631 packages and 7,371 sources, with modules checked before removal. The deletion scenarios themselves were constructed. They show the algorithmic cost but don't show a common workflow. For example, removing 100 sources cut the LSP watched-file handler median from 287 ms to 38 ms. Removing a single source doesn't benefit.
Why defer
- Deletions in a repository are usually sparse. Restarting the language server is a reasonable workaround for an occasional large batch.
- Branch switching might benefit, but it hasn't been measured. It also produces a mix of events rather than long runs of removals.
Revisit this after a real branch-switch or folder-removal trace shows a noticeable stall. At that point, measure the time to fresh diagnostics rather than claiming full-editor or cold-build gains.
Detailed measurements and prototype patches are in the investigation thread (Amp access required).
- 主要言語
- Rust
- スター
- 123
- フォーク
- 12
- 平均マージ
- 7時間 3分
- マージ済み PR（30日）
- 110
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
purefunctor/purescript-iris のほかの issue
-
diagnostics enhancement language-server
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
purefunctor/purescript-iris#648 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
purefunctor/purescript-iris#613 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
purefunctor/purescript-iris#560 ·
メンテナーはふだん 1 日以内に返信
-
tooling
難易度 4/5 3〜5日 初心者へのやさしさ 58/100
purefunctor/purescript-iris#507 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
purefunctor/purescript-iris#264 ·
メンテナーはふだん 1 日以内に返信
purefunctor/purescript-iris の issue をすべて見る
似ている issue
-
難易度 1/5 1〜3時間 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信
-
area:sim good first issue kind:feature
難易度 2/5 1〜3時間 初心者へのやさしさ 87/100
メンテナーはふだん 1 日以内に返信
-
The demo's interval button and chart legend keep the previous interval after an interval changeオープンbug ui
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
userFRM/egui-charts#670 ·
メンテナーはふだん 1 日以内に返信
-
docs good first issue
難易度 1/5 1〜3時間 初心者へのやさしさ 84/100
Usenova-Labs/usenova-backend#35 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
lugassawan/swe-workbench#823 ·
メンテナーはふだん 1 日以内に返信