Janusz Wrobel

>Did you build the solution, before running the design-time build? When it is not built it is much faster, but that is not the use case we care about. What...

I did some profiling and realized that GC plays quite a role in slowing the main MSBuild process down. I then ran the following test with and without server GC:...

Nice to see this getting traction 👍 FYI I created https://github.com/safesparrow/fsharp-benchmark-generator for automating FCS testing. I was planning to add more examples there and make it more robust, but not...

FWIW I'm getting this pretty consistently, seeing >=20GB memory used and lots of disk swap happening, making the build very slow. These are the last projects that build mostly fine:...

I ran DotMemory for `./build.cmd -noVisualStudio`, here is a snapshot from one of the processes. It's quite clear that `CollectionTracing.Entry` is to blame:

Ok, confirmed that the above was an issue with my local environment and doesn't apply more widely, so please ignore my previous claims of the build taking 20GB+. Details: I...

I have provided some test results which show the performance impact. @vzarytovskii Would it be possible to consider this change? As mentioned in the description there are tweaks to be...

>We will also probably need a flag passed to checker, and a VS feature flag (for easier in-VS testing, which will be shown in the settings). Makes sense. @auduchinok if...

> >Regarding VS: > > What's special about it? > If I am not mistaken, it pretty much has its own [threading model/primitives](https://github.com/microsoft/vs-threading) which may affect the behaviour here. I...

I have now wired up the feature setting from top-level in both FSC and `FSharpChecker`. The user can opt-in to the feature by setting the environment variable `FCS_ParallelReferenceResolution=true`, or through...