F# Performance Test – Structs vs Records

In F#, you have the choice of using a struct or a record as a lightweight container for data. The similarities between the two are striking – both are immutable by default, neither can be inherited, and they both offer structural equality semantics by default too!

However, there’s a key difference between them, their performance characteristics.

When you’re dealing with tons of small objects, structs offer significant performance benefits because as value types they are stack allocated which is much faster, and don’t need to be garbage collected.

Records on the other hand, are reference types, and are therefore heap allocated (plus pointers on the stack), which is slower, and require the extra step of garbage collection when they’re no longer referenced.

As a simple test, given these two identical types, one as a struct and one as a record:


The snippet below constructs two arrays each with 10 million items, one with struct instances and the other with record instances:


Over three runs, the structs array took an average of 0.146 seconds to construct whilst the records array took an average of 2.919 seconds!

Parting Thoughts…

Although this test shows that creating large numbers of records takes significantly longer than structs, in practice however, would you really care if generating 10 millions objects takes 3 seconds instead of 0.1? Is that likely to be the source of your performance issues?

All and all, the performance gains you get by using structs over records is negligible, in most cases you won’t be generating large number of these objects frequently enough for you to notice the difference. Also, we haven’t even covered the cost of copying them when passing them as parameters (Value types are passed by value as opposed to reference), which if you’re not careful can have a detrimental effect on the overall performance of your application.

Also, records have two very useful features for working with F# which structs don’t:

  • type inference can infer a record’s type, no need for type annotation
  • records can be used as part of standard pattern matching, no need for when guards

both are big pluses in my book and worth considering when you’re choosing between records and structs.


  1. Carsten   •  


    there are some minor issues here. First creating the objects on heap is very cheap – it’s the GC step that’s causing the pain and here I have to disagree with your conclusion.
    3s vs. 0.1s is not a big deal? Really?
    IMHO this is a very big deal as 10mio. objects might be big if you think on big buisiness objects but from time to time you process *smaller* data like points or small values. These are the places where F# really shine – processing large quantities of data – and of course 3s vs. 0.1s. matters a LOT in those cases.

  2. Pingback: Contrasting F# and Elm’s record types | theburningmonk.com

Leave a Reply

Your email address will not be published.