Problem or motivation
Warm-cache runs should be very fast, but it is hard to see where time is spent and some hot-path work is still repeated even when cached results are available.
Areas that can affect warm-cache performance include:
- repeated file content hashing
- cache entry read/parse/validation overhead
- cache write serialization and I/O
- unnecessary mutex contention around cache stats/lookups
- repeated config/rule hash work
- discovery overhead before linting
- profiling timers that depend on shared global start/stop state
- building file indexes and running cross-file checks around cached single-file warnings
Without finer profiling and cache-path optimization, regressions in warm-cache performance are hard to diagnose.
Proposed solution
Add a broader warm-cache optimization/profiling path.
Implementation shape from the branch:
- Make cache stats internally synchronized so cache methods can take
&self instead of requiring broader mutable locking.
- Support precomputed file hashes for cache get/set operations to avoid hashing content more than necessary.
- Add reason-preserving cache lookup APIs for diagnostics.
- Instrument cache hashing, cache read, parse, serialize, and write sections under the profiling feature.
- Refactor processing/check-run paths so warm-cache operations avoid unnecessary work where possible.
- Improve profiling reporting to describe total measured time, noting that parallel sections may overlap.
- Change scoped profiling timers to record elapsed duration directly rather than relying on shared active-timer start/stop bookkeeping.
- Include discovery optimizations such as compiled exclude matchers and walker file-type checks.
Alternatives considered
Only add more profiling labels without changing the cache path. That would improve visibility but would not address the repeated work visible in warm-cache runs.
Feature category
Performance
Example markdown
Contribution
Additional context
No response
Problem or motivation
Warm-cache runs should be very fast, but it is hard to see where time is spent and some hot-path work is still repeated even when cached results are available.
Areas that can affect warm-cache performance include:
Without finer profiling and cache-path optimization, regressions in warm-cache performance are hard to diagnose.
Proposed solution
Add a broader warm-cache optimization/profiling path.
Implementation shape from the branch:
&selfinstead of requiring broader mutable locking.Alternatives considered
Only add more profiling labels without changing the cache path. That would improve visibility but would not address the repeated work visible in warm-cache runs.
Feature category
Performance
Example markdown
Contribution
Additional context
No response