Any problems if a distinguishable union has many options?

Question

Yes, a trivial question, but I could not find an expert opinion on this matter.

I use calculation expressions for a sequence of server processes. It helps me a lot when my functions have the same signature, so I have a discriminatory union with various combinations defined inside it. I have a couple of quick, start-up questions.

• Is there a recommended upper limit on the number of options that a DU can have? My DU currently has nine options, but that number will increase as the project progresses. What if I remove 30 or 40 by the end of the project?

• Can a problem arise if some of the parameters get "long"? Currently, the middle version has about four or five basic types - something like bool * string * XElement * int * string - but the longest has the following definition:

  bool * int * int * int * string * XElement * XElement * DateTime option * DateTime option * string * Dictionary * Dictionary

I do not expect many options to be anywhere longer than this. But can I tune in to a world of pain in terms of performance?

Thanks in advance.

Answer 1

I think you can safely assume that everything will work well if the size of your data type is similar to the size of the data types used by the F # compiler - the performance of the F # compiler is what the F # team definitely looked and therefore I think that they They also conducted several experiments to ensure that the discriminatory unions they use work effectively.

• As for the number of cases, there are more than 50 cases in the discriminated union (see source code ) in SynExpr , so I think this should be good.

  Pattern matching on a discriminatory union is compiled using the switch IL operation code for an integer, so you can try to do some research on the effectiveness of this if you want to make sure. Also, if you just use match to search for one specific case, then it should be just a one-piece comparison, regardless of the number of other cases.

• Regarding the number of fields, in the longest case, SynExpr has 7 fields, but I suppose you can find other DUs that are longer in length. (I think the biggest problem with this number of attributes is readability because the attributes are unnamed. Therefore, I think that using a record for a large number of attributes that are logically related to each other might be better.)

I think the DU size you described should be great, but I have not tested performance testing myself, so if you really want to make sure, you need to measure it. (But, as I said, I'm sure this is what has been tested as part of the development of the F # compiler)

Answer 2

If I need memory, I believe that there were some performance problems with deeply nested pattern matches in DU with a large number of cases / fields in each case, but that was before 2.0, and I believe that they fixed the implementation in such a way that in these scenarios are currently well optimized and have no egregious performance issues. (sorry, do not quote).

But even when optimizing DU de sugar in a rather large amount of code. Thus, even if they can work (and probably better) than any equivalent manual control flow, there is a possibility that you could overflow the stack with the simple number of instructions emitted for the function / method body (but that would be pretty a complicated scenario, since the .NET stack size by default is ~ 1 MB, however, it can certainly lead to an earlier than usual stack overflow in a non-recursive method / function not associated with the tail, including a large DU match, but again it is unlikely to such an extent that you should really be wary of this scenario).

I do not believe that this will change the performance characteristics (since we are talking about heaps of selected objects anyway), but for convenience / readability it sometimes helps to wrap your DU type data in a record type so that data fields are called and pattern matching in a subset of data fields simpler (e.g. {Name="Stephen"} instead of (_,_,_,_,_,_,_,"Stephen",_,_,_,_,_) ). (@TomasPetricek beat me up to this offer, did not see that I read his answer on my first)