Idea: Coalesce cache scans for batched source removal
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
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.
Written by the indexing model from the issue text.
Description
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).
- Dominant language
- Rust
- Stars
- 117
- Forks
- 11
- Avg merge
- 6h 52m
- Merged PRs (30d)
- 119
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from purefunctor/purescript-iris
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
purefunctor/purescript-iris#613 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
purefunctor/purescript-iris#560 ·
Maintainers usually reply within 1 day
-
tooling
Difficulty 4/5 3-5 days Newbie friendliness 58/100
purefunctor/purescript-iris#507 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
purefunctor/purescript-iris#264 ·
Maintainers usually reply within 1 day
-
[checking] elide_missing_patterns does not account for Partial via superclass entailmentMay be free again @purefunctor claimed this 132 days ago, and no pull request is open. Openchecking semantics
purefunctor/purescript-iris#147 · 1 assignee ·
Maintainers usually reply within 1 day
All issues in purefunctor/purescript-iris
Similar issues
-
security-scan
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
content good first issue
Difficulty 2/5 Under an hour Newbie friendliness 68/100
StudentSuite/awesome-skills-plugins-for-students#293 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
gfx-rs/wgpu-native#636 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day