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!
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.
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my new course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, callbacks, nested workflows, design patterns and best practices.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong