FSharp.Compiler.Service: update tagged collections with new implementation from FSharp.Core

[buybackoff]

Copied new implementation from #10188 and #10190

Differences are:

• TaggedCollections used fat leaves (Left/Right/Height present always). There are 2xN objects in the tree, of which N are leaves. Fat leaves give 20 (24 aligned) x N. More memory, worse memory locality, more GC are not good for perf.
• TaggedCollections did not use optimized closures. Not sure if they are useful, but in many cases it's noop if f' was already in the right shape.

Copying the source opens the possibility to move MapTree and SetTree code to separate files and reuse a single implementation in both places.

[cartermp]

I think these look good overall, but this will require a @dsyme check as per here: #10188 (comment)

Though I do personally think we should consolidate on the FSharp.Core implementations

[buybackoff]

I have profiled fsc while it builds FSharp.Core.UnitTests in PerfView/dotTrace/dotMemory and couldn't see anything related to Set/Map on the top lines (CPU/allocations). But there is 50% "native or optimized code" - may it hide there after ngen?

[cartermp]

This comes into play more with tooling like in VS than anything else. Various parts of the compiler will hold data in memory for a long time and process it to varying degrees. So any improvements to that processing time and memory usage will be a win. Like most perf improvements, it'll be incremental but will work to make things a lot better over time.

[dsyme]

I have profiled fsc while it builds FSharp.Core.UnitTests in PerfView/dotTrace/dotMemory and couldn't see anything related to Set/Map on the top lines (CPU/allocations). But there is 50% "native or optimized code" - may it hide there after ngen?

My understanding is that type inference is pretty heavily affected by Set performance, at least in some situations (e.g. possibly lots of unsolved type inference variables interacting with generalization)

Set and Map nodes do occupy a significant chunk of memory and allocations as well.

It would be good to get baselines. I'll try to resurrect the compiler performance script for use with .NET Core.

[dsyme]

It would be good to get baselines. I'll try to resurrect the compiler performance script for use with .NET Core.

I don't see this as blocking merging the PR, which is fantastic work, thank you!

[forki]

Wow.

[buybackoff]

My understanding is that type inference is pretty heavily affected by Set performance, at least in some situations (e.g. possibly lots of unsolved type inference variables interacting with generalization)

I wonder if structural sharing is important, or thread safety? It looks like only one CPU is busy during the build time.