add a way to efficiently map many project options to FCS options at once

[baronfel]

Closes #155 by providing an all-in-one mapping function in addition to the one-shot mapping function. Would like to grab some of the dense tests from dotnet/fsharp to verify before merging.

[safesparrow]

Any chance to get this merged and released @baronfel ?

I used a custom version fsharp-benchmark-generator to run a test and show this does work as expected.
Generator code: https://github.com/safesparrow/fsharp-benchmark-generator/tree/projinfo-update
It uses the new FCS.mapManyProjects function.

You can use the following script to reproduce the test:

# Set the path to the local ProjInfo project
$projInfoPath = "C:\projekty\proj-info\src\Ionide.ProjInfo.FCS\Ionide.ProjInfo.FCS.fsproj"
# Set the path to where the git checkouts should be stored. Must be short on Windows due to long path issues.
$artifactPath = c:/.artifacts

# Checkout benchmark generator
git clone https://github.com/safesparrow/fsharp-benchmark-generator
Push-Location fsharp-benchmark-generator
git checkout projinfo-update
dotnet build .\Benchmarks.Generator.fsproj /p:ProjInfoProjectPath=$projInfoPath

dotnet run --no-build -- -i .\inputs\stress_big_dense.json --dry-run -n 1 -v -c $artifactPath

Pop-Location

The relevant output should look something like this, indicating that the FSharpOptions generation took a very short time:

[01:17:42 INF] LoadOptions: 30 projects loaded from c:\.artifacts\stress_big_dense\a7b668136cc720e50b92b0cae0f06081c5df1117\tests/projects/stress/big_netstandard/dense/Dense.sln
[01:17:42 VRB] PrepareAndRun: Generating actions

I do have one request for the PR:

• Can we make FCS.mapToFSharpProjectOptions use the same caching mechanism? The problem occurs always when the project graph is not a tree. It doesn't matter whether the user calls the function for each project independently or for the root project.

[baronfel]

I was thinking about the method a bit: I worried about making it use the same caching mechanism because it would allocate a new caching dictionary on every call. Maybe not the worst thing but it was a little concerning to me.

I think the other thing I was trying to do was figure out a good way to bring these two under test. Ideally I'd like to verify that we don't regress the perf.

[safesparrow]

I was thinking about the method a bit: I worried about making it use the same caching mechanism because it would allocate a new caching dictionary on every call. Maybe not the worst thing but it was a little concerning to me.

Every call allocates a big number of large objects already. I really don't think that one temporary dictionary is something to worry about at all IMO.

Regarding perf: a simple test would be to construct a dense project graph on disk, process that and:

1. Assert that the number of unique options objects equals the number of projects (as a proxy for whether a project was analysed multiple times).
2. Inject a counter to the method and achieve the same thing more explicitly.

[baronfel]

Thank you for your help @safesparrow!