theburningmonk.com

In F#, you have the choice of using a struct or a record as a light­weight con­tainer for data. The sim­i­lar­i­ties between the two are strik­ing – both are immutable by default, nei­ther can be inher­ited, and they both offer struc­tural equal­ity seman­tics by default too!

How­ever, there’s a key dif­fer­ence between them, their per­for­mance char­ac­ter­is­tics.

When you’re deal­ing with tons of small objects, structs offer sig­nif­i­cant per­for­mance ben­e­fits because as value types they are stack allo­cated which is much faster, and don’t need to be garbage collected.

Records on the other hand, are ref­er­ence types, and are there­fore heap allo­cated (plus point­ers on the stack), which is slower, and require the extra step of garbage col­lec­tion when they’re no longer referenced.

As a sim­ple test, given these two iden­ti­cal types, one as a struct and one as a record:

The snip­pet below con­structs two arrays each with 10 mil­lion items, one with struct instances and the other with record instances:

Over three runs, the structs array took an aver­age of 0.146 sec­onds to con­struct whilst the records array took an aver­age of 2.919 sec­onds!

Part­ing Thoughts…

Although this test shows that cre­at­ing large num­bers of records takes sig­nif­i­cantly longer than structs, in prac­tice how­ever, would you really care if gen­er­at­ing 10 mil­lions objects takes 3 sec­onds instead of 0.1? Is that likely to be the source of your per­for­mance issues?

All and all, the per­for­mance gains you get by using structs over records is neg­li­gi­ble, in most cases you won’t be gen­er­at­ing large num­ber of these objects fre­quently enough for you to notice the dif­fer­ence. Also, we haven’t even cov­ered the cost of copy­ing them when pass­ing them as para­me­ters (Value types are passed by value as opposed to ref­er­ence), which if you’re not care­ful can have a detri­men­tal effect on the over­all per­for­mance of your application.

Also, records have two very use­ful fea­tures for work­ing with F# which structs don’t:

• type infer­ence can infer a record’s type, no need for type annotation
• records can be used as part of stan­dard pat­tern match­ing, no need for when guards

both are big pluses in my book and worth con­sid­er­ing when you’re choos­ing between records and structs.

In my pre­vi­ous post on dis­crim­i­nated unions, I pre­sented dis­crim­i­nated unions as an alter­na­tive to stan­dard .Net classes to rep­re­sent hier­ar­chi­cal data struc­tures. How­ever, in terms of data struc­ture, dis­crim­i­nated unions share much more sim­i­lar­i­ties with enums than they do classes – both allow you to define a set of named con­stants and asso­ciate some data with these constants.

The syn­taxes for cre­at­ing enums and dis­crim­i­nated unions in F# are very sim­i­lar too:

Despite their appar­ent sim­i­lar­i­ties, there are some sig­nif­i­cant dif­fer­ences between the two:

• Enums don’t offer a safety guarantee
• Enums only hold one piece of data
• Dis­crim­i­nated unions are ref­er­ence types
• Enums can be used as bit flags

Now let’s take a closer look at these differences.

Enums don’t offer a safety guarantee

As enums are lit­tle more than syn­tac­tic sugar over a prim­i­tive inte­gral type such as int, there is no guar­an­tee that the value of an enum is valid. For instance, it’s pos­si­ble to cre­ate an instance of an enum type with an inte­gral value that is not asso­ci­ated with one of the named constants:

it’s easy to see how bugs can creep in when you mis­tak­enly cre­ate enum val­ues that don’t make any sense, espe­cially when you’re work­ing with enum val­ues from exter­nal sources. Which is why it’s a good prac­tice to check the enum val­ues with the sta­tic Enum.IsDefined method.

Dis­crim­i­nated unions, on the other hand, can only be one of the defined val­ues, any attempts to do oth­er­wise will be met with a swift com­piler error!

Enums only hold one piece of data

This one is self evi­dent from the ear­lier snip­pet, enums only hold one piece of data but dis­crim­i­nated unions hold a tuple of data.

Dis­crim­i­nated unions are ref­er­ence types

Enums are value types and instances of an enum type there­fore reside on the stack as a few bytes. Dis­crim­i­nated unions, as do all other ref­er­ence types, reside in the heap (plus a pointer on the stack whilst it’s still ref­er­enced) and need to be garbage col­lected when they are no longer referenced.

The impli­ca­tion of this is such that enums offer sig­nif­i­cant per­for­mance ben­e­fits over dis­crim­i­nated unions. Take the fol­low­ing snip­pet for instance, where I pop­u­late two arrays with 10 mil­lion items, one with enums and the other dis­crim­i­nated unions.

Aver­aged over three runs, the enum array took 0.048 sec­onds to fin­ish whilst the dis­crim­i­nated union array took 1.919 sec­onds!

Enums can be used as bit flags

From MSDN:

You can use an enu­mer­a­tion type to define bit flags, which enables an instance of the enu­mer­a­tion type to store any com­bi­na­tion of the val­ues that are defined in the enu­mer­a­tor list.