GetMemberTypeInFSharpForm produces indirectly produces a large amount of Tuple instantiations causing UI delays in VS

[davkean]

Trace: https://developercommunity.visualstudio.com/content/problem/245786/slow-f-editing-experience-up-to-a-minute-until-typ.html

GC Rollup By Generation

Gen	Count	MaxPause	MaxPeak MB	Max AllocMB/sec	TotalPause	TotalAlloc MB	Alloc MB/MSec GC	Survived MB/MSec GC	MeanPause	Induced
ALL	5196	1,652.0	744.6	8,424.125	40,245.7	29,166.1	0.7	1.026	7.7	18
0	3869	886.0	744.6	8,424.125	14,865.1	20,456.4	0.5	0.083	3.8	0
1	1286	53.5	744.6	3,284.108	17,473.7	8,524.0	0.6	0.746	13.6	0
2	41	1,652.0	744.6	502.652	7,906.8	185.7	0.3	7.355	192.8	18

This method indirectly causes large amounts of allocations, in above trace we're talking 6 GB:

Of which are made up of nearly entirely Tuples or lists of Tuples:

I don't know enough about this method to know if this needs to broken up further into a little more actionable task.

[forki]

from first look: GetTopTauTypeInFSharpForm looks Ok.
would it make sense to use valuetuple? they would still be in lists - so I guess not!?

[TIHan]

To note, just from experience, I have tried changing tuples similar to this to value tuples and the results were minimal. The copying of value tuples can be more expensive thus not really helping much. The benefit it relieves GC pressure, but it's hard decide: more copying and less GC pressure, or no copying and GC pressure? It depends on the scenario.

[davkean]

I would evaluate why we are allocating this much data in such a short period. This is 6GB (only 20% of the trace!) of data over a couple of minutes. We must be missing caches, not caching enough or need a better algorithm.

For a comparison, I'm looking at the trace of a load of a solution with 780 C# projects and 30 seconds after load; it allocates 2 GB in total over that entire period and I'm filing bugs to remove 30MB here and 50MB there.

[forki]

Yes I assume the problem is on higher level. As I said above the function itself looks OK. At least I dont see obvious performance problems in it. Am Do., 22. Nov. 2018, 08:45 hat David Kean <notifications@github.com> geschrieben:

…

I would evaluate why we are allocating this much data in such a short period. This is 6GB (only 20% of the trace!) of data over a couple of minutes. We must be missing caches, not caching enough or need a better algorithm. For a comparison, I'm looking at the trace of a load of a solution with 780 C# projects and 30 seconds after load; it allocates 2 GB *in total* over that entire period and I'm filing bugs to remove 30MB here and 50MB there. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5938 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNPDl7ePzn3MmRyqIWMZuHIQFyo_Iks5uxlYagaJpZM4Yqd2K> .

[gerardtoconnor]

@davkean There are a lot of allocs due to heavy use of linked lists, tuples & immutable AVL tree (map) construction throughout (incl DU) but in general overuse of temporary (bulky) data structures. It is consistent throughout so would be a lot of work to change the fundamental design, introducing more algos & mutable states/structures. Your analysis will hopefully uncover some memory bugs that can be easily fixed or improved as we clearly need to reduce the heavy memory bloat.

One of the things that comes to mind on these tuple lists are that they could be converted to enumerators, avoiding loads of temp lists, so only a few persisted structures need to be kept in memory?

[cartermp]

We'll need to spend more time looking at this particular trace to see if there's an easy win here or not. For example, the function in the issue title just directly uses the results of [this function](https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/TastOps.fs#L1566, so maybe there's more investigative work involved.

One of the goals of doing this analysis work is identifying if there is an easy win (e.g., #5941) vs. something that is fundamental to the design.

[gerardtoconnor]

I can look into doing a PR for this if you like? if you do not want to do drastic changes than I can change usages of GetTopValTypeInFSharpForm , splitting it out into multiple more specialised functions as at the moment we use it like 8 time like a sledge hammer on drawing pins (eg we transform full lists of args ect to new lists of stuff … just to see if the list is empty!?!) Given these are called multiple times at different places, by potentially the same value, it might be candidate for caching but we should probably profile that as may be unique calls so would just be clogging memory up worse?

[gerardtoconnor]

An example of my proposal is as follows:
for each method calling GetTopValTypeInFSharpForm / GetTopTauTypeInFSharpForm function (and similar), here is IsCompiledAsStaticProperty, I inline the calls and short cut the logic to achieve the same pattern so the current def of

let IsCompiledAsStaticProperty g (v:Val) =
    match v.ValReprInfo with
    | Some valReprInfoValue ->
         match GetTopValTypeInFSharpForm g valReprInfoValue v.Type v.Range with 
         | [], [], _, _ when not v.IsMember -> true
         | _ -> false
    | _ -> false

Goes to my new refactored version of

let IsCompiledAsStaticProperty g (v:Val) =
    if v.IsMember then
        false
    else
        match v.ValReprInfo with
        | Some (ValReprInfo (ntps, argInfos, _)) ->
            match ntps , argInfos with
            | [] , [] -> isForallTy g v.Type |> not
            | _ -> false
        | _ -> false

Although it looks like same, it computes and allocates significantly less as I traced how the lists map and this achieves same result, all the mappings inside GetTopValTypeInFSharpForm are not needed in this instance. I can refactor and reduce down each of the usages of these functions so all the extra work for data not needed is not computed?

[cartermp]

@gerardtoconnor We'd certainly welcome help! I think the main thing is establishing a good perf test. A good first start could be to use this: https://github.com/Microsoft/visualfsharp/blob/master/tests/scripts/compiler-perf.fsx

[gerardtoconnor]

@cartermp are the compiler perf tests not already operational with this script? I was going to do the PR, and include "[CompilerPerf]" in the title so that I (we) could then run a comparison with master to verify it had produced the improvement?

My example above turned out to be the simplest case where given there were no list reductions, only mappings, we could match empty on the source lists without mapping. The rest are more tricky and seems like we may need some cache/algo strategy. ValReprInfo type may be a candidate to structurally tweak with a cache graph, will investigate and let you know if I find anything useful

[cartermp]

Sorry, I should have clarified - we'll likely want to verify memory usage in a scenario that stresses these code paths. I don't think the existing scrips do this, but that area would be where to add one.