VS sometimes runs more than one incremental builder for the same project

[majocha]

This causes wasted CPU work and multiplied allocations. It does not seem intentional.

[0101]

It's expected to have multiple builders per project under some circumstances. Notably when any references are updated.

fsharp/src/Compiler/Service/IncrementalBuild.fs

Lines 1148 to 1149 in f165358

	if referencesUpdated then
	// Build is invalidated. The build must be rebuilt with the newly updated references.

There's also a lot going on with FSharpProjectOptions processing on VS startup, which could possibly also generate multiple options for one project which are not AreSameForChecking and thus would produce multiple builders.

[majocha]

I wonder what's going on here:

fsharp/src/Compiler/Service/service.fs

Lines 426 to 445 in ea5a144

	let getOrCreateBuilder (options, userOpName) : NodeCode<IncrementalBuilder option * FSharpDiagnostic[]> =
	match tryGetBuilder options with
	| Some getBuilder ->
	node {
	match! getBuilder with
	| builderOpt, creationDiags when builderOpt.IsNone || not builderOpt.Value.IsReferencesInvalidated -> return builderOpt, creationDiags
	| _ ->
	// The builder could be re-created,
	// clear the check file caches that are associated with it.
	// We must do this in order to not return stale results when references
	// in the project get changed/added/removed.
	parseCacheLock.AcquireLock(fun ltok ->
	options.SourceFiles
	|> Array.iter (fun sourceFile ->
	let key = (sourceFile, 0L, options)
	checkFileInProjectCache.RemoveAnySimilar(ltok, key)))
	return! createAndGetBuilder (options, userOpName)
	}
	| _ -> createAndGetBuilder (options, userOpName)

when builderOpt.IsNone -> return builderOpt does not feel right or intended.

[majocha]

It's expected to have multiple builders per project under some circumstances. Notably when any references are updated.

fsharp/src/Compiler/Service/IncrementalBuild.fs

Lines 1148 to 1149 in f165358

	if referencesUpdated then
	// Build is invalidated. The build must be rebuilt with the newly updated references.

There's also a lot going on with FSharpProjectOptions processing on VS startup, which could possibly also generate multiple options for one project which are not AreSameForChecking and thus would produce multiple builders.

The problem I've seen is not only them being created but both running to completion, parsing and typechecking everything twice. This however seem to happen in VS only for the first file opened, and not the subsequent ones.

So it's more of a glitch than a showstopper after all 😀

[majocha]

I've also seen VS not cancelling the type check when it should. For example closing the solution will not stop the type check.
If the project options update a few times during solution load, and in the meantime some analyzers are being run on the opened documents, and they don't cancel on project options change, we would see multiple typechecks running in parallel on the same files. That's what I sometimes observe.

[auduchinok]

I think I could've seen it in Rider too some time ago. It's OK if there are multiple builders for the same project given that the options are different (e.g. different target frameworks, or before/after a project modifications), but it seems that there should be no builders that have the same options, I'd expect them to be shared in such a case.