Skip to content

Enable TypeSubsumptionCache for IDE use #18499

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

majocha
Copy link
Contributor

@majocha majocha commented Apr 24, 2025

Description

This builds upon Vlad's work from #18190 and #17668, extending the fix for #17501 into incremental compilation / typecheck in IDE editor.

This is resubmitted and cleaned up #18468.
TODO:
tests, comments, write-up, discussion

Checklist

  • Test cases added

  • Performance benchmarks added in case of performance changes

  • Release notes entry updated:

    Please make sure to add an entry with short succinct description of the change as well as link to this pull request to the respective release notes file, if applicable.

    Release notes files:

    • If anything under src/Compiler has been changed, please make sure to make an entry in docs/release-notes/.FSharp.Compiler.Service/<version>.md, where <version> is usually "highest" one, e.g. 42.8.200
    • If language feature was added (i.e. LanguageFeatures.fsi was changed), please add it to docs/release-notes/.Language/preview.md
    • If a change to FSharp.Core was made, please make sure to edit docs/release-notes/.FSharp.Core/<version>.md where version is "highest" one, e.g. 8.0.200.

    Information about the release notes entries format can be found in the documentation.
    Example:

    If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

Copy link
Contributor

❗ Release notes required

@majocha,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path Release notes path Description
src/Compiler docs/release-notes/.FSharp.Compiler.Service/9.0.300.md No release notes found or release notes format is not correct
vsintegration/src docs/release-notes/.VisualStudio/17.14.md No release notes found or release notes format is not correct

@majocha majocha changed the title Enable TypeSubSumptionCache in IDE use Enable TypeSubsumptionCache for IDE use Apr 24, 2025
@@ -106,15 +133,13 @@ type [<Struct; NoComparison; CustomEquality>] TTypeCacheKey =
type ImportMap(g: TcGlobals, assemblyLoader: AssemblyLoader) =
let typeRefToTyconRefCache = ConcurrentDictionary<ILTypeRef, TyconRef>()

let typeSubsumptionCache = ConcurrentDictionary<TTypeCacheKey, bool>(System.Environment.ProcessorCount, 1024)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In incremental mode ImportMap get created quite a lot, so this had to be attached somewhere else.

open System.Diagnostics.Metrics

[<Struct; RequireQualifiedAccess; NoComparison>]
type EvictionMethod =
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed Blocking eviction method for now. It's another thing that would rot, because it's unused.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree

member _.Remove(_) = ()
}

type ICacheEvents =
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are events needed or should we just use Metrics counters directly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was added for observability.
If we can use metrics for it, it serves better.

(also less worries about loose GC handles IMO)

use meterProvider =
OpenTelemetry.Sdk.CreateMeterProviderBuilder()
.AddMeter(nameof FSharp.Compiler.CacheInstrumentation)
.AddMeter("System.Runtime")
Copy link
Contributor Author

@majocha majocha Apr 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "System.Runtime" meter works only for net9.0 but is actually quite awesome. GC, memory, and lots of other metrics can be viewed in Prometheus in real time while the tests run. I use a simple docker setup like this

// FSI-LINKAGE-POINT: unsited init
do FSharp.Interactive.Hooks.fsiConsoleWindowPackageCtorUnsited (this :> Package)

// Uncomment to view cache metrics in the output window
// do Logging.FSharpServiceTelemetry.logCacheMetricsToOutput ()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cache metrics viewable directly in VS output window.

let private overrideVariable = "FSHARP_CACHE_OVERRIDE"

/// Use for testing purposes to reduce memory consumption in testhost and its subprocesses.
let OverrideMaxCapacityForTesting () =
Copy link
Contributor Author

@majocha majocha Apr 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, the settings that work best irl are not great for the CI. I'm still not sure what's going on, so this is an attempt.

let options =
match Environment.GetEnvironmentVariable(overrideVariable) with
| null -> options
| _ -> { options with MaximumCapacity = 1024 }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we have got:

CacheOptions.Default.MaximumCapacity => That one is never used ... ?

createTypeSubsumptionCache depending on the options.

and this piece overrides it agnostic of the options (I guess it assumes that CI run is always one-off and isolated, and works with a very small cache intentionally).

?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes the idea is to override only the MaximumCapacity when run in testhost process. We call OverrideMaxCapacityForTesting () at the start of xUnit test run. The env var should propagate to app domains on net472, and even subprocesses that we start a lot.

Copy link
Member

@T-Gro T-Gro Apr 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok that makes sense.
I agree to rather have small cache than no-cache at all for CI, so that we aspire to keep a higher level of dogfooding

majocha added 2 commits April 25, 2025 14:08
deal with memory restrictions in CI, dispose caches
@@ -108,7 +108,9 @@ let createTypeSubsumptionCache (g: TcGlobals) =
MaximumCapacity = 4 * 32768 }
Cache.Create<TTypeCacheKey, bool>(options)

let typeSubsumptionCaches = ConditionalWeakTable<TcGlobals, Cache<TTypeCacheKey, bool>>()
let typeSubsumptionCaches = Cache.Create<TcGlobals, Cache<TTypeCacheKey, bool>>({ CacheOptions.Default with MaximumCapacity = 16 })
Copy link
Contributor Author

@majocha majocha Apr 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Each cache held here roughly corresponds to one assembly being built / one incremental builder. My understanding is that there is not much turnover here, unless something on the project level changes.
In a test run the story is different, hundreds can be created and disposed.

Now, that kind of asks for LFU.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't LRU be also fitting here?
If a project does not need a cache (= likely is not getting touched for many minutes...) for a longer time, just get rid of it?

@majocha
Copy link
Contributor Author

majocha commented Apr 25, 2025

Performance of this is clearly off. I think I fixed the excessive memory use in CI (notwithstanding the Linux leg memory warnings, but they were always there ), but still, it runs much slower than main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: New
Development

Successfully merging this pull request may close these issues.

2 participants