Performance: parallel per-file type checking#846
Draft
michaelglass wants to merge 2 commits intofsprojects:masterfrom
Draft
Performance: parallel per-file type checking#846michaelglass wants to merge 2 commits intofsprojects:masterfrom
michaelglass wants to merge 2 commits intofsprojects:masterfrom
Conversation
Rather than reading it from FSharpCheckProjectResults on every use, which appears to have a substantional performance cost. refs fsprojects#770
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
Contributor
|
Fwiw I was having a go at passing the project options down from the top in #845 which avoids some of this overhead and avoids a larger perf regression when using the .NET 10 version of FCS, not sure what the best approach is though. |
Author
|
oh nice. Yeah I've been doing a deeper dive on fsharplint perf because on one of my projects, it takes 5 minutes to run. |
michaelglass
force-pushed
the
perf/skip-type-check-and-fix-async-naming-overhead
branch
from
a8bc0ec to
c7de224
Compare
michaelglass
changed the title
Author
|
going to rebase on your PR, I think that approach is better. |
michaelglass
force-pushed
the
perf/skip-type-check-and-fix-async-naming-overhead
branch
from
c7de224 to
827ee64
Compare
Run ParseAndCheckProject and per-file ParseAndCheckFileInProject concurrently using Async.Parallel. The project check warms the FCS incremental builder; parallel per-file checks share the builder and benefit from its warmed state. Also enable parallelReferenceResolution on FSharpChecker. Benchmarked on a 24-file project: ~145s sequential to ~18s parallel. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
michaelglass
force-pushed
the
perf/skip-type-check-and-fix-async-naming-overhead
branch
from
827ee64 to
b69d240
Compare
michaelglass
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Massive performance improvement to the linting pipeline, built on top of #845.
Runs
ParseAndCheckProjectand per-fileParseAndCheckFileInProjectconcurrently usingAsync.Parallel. The project check warms the FCS incremental builder; parallel per-file checks share the builder and benefit from its warmed state.Also enables
parallelReferenceResolutiononFSharpChecker.Create.Performance
The speedup scales with file count — larger projects see dramatically larger gains.
Test plan
A note on this PR
This PR was developed with significant AI assistance. I understand if that's not welcome — apologies if so. Happy to discuss the changes or withdraw the PR.
🤖 Generated with Claude Code