I tend to use immutable types in my programs a lot and tend to find the performance is very good. If you do micro bench marking of immutable/mutable then mutable is always going to come out faster. However in my experience this not were the bottle necks in programs are so using immutable structures doesn’t affect overall program performance. Immutable structures use a small amount of computational performance, modern programs tend to I/O bound rather than computationally bound. The amount of extra computation performance tends to be insignificant. I’ve built large programs only using immutable structures and I’ve been very happy with the overall performance. Take a look at the some of the collective intelligence samples on git hub for more details: [link:github.com]

Immutable types have a bad image somewhat unfairly because of .NET string class. If you need to build up large strings though concatenation then you will see poor performance because each time you perform a concentration an entirely new string is created, and if the string is large then it’s going to be based on a large buffer.

Most immutable types in F# do no work like this. For example when concatenating values to an F# immutable list the pervious list is not recreated, the existing list is reused and the new node is added to the end. This means the two lists now “share” some of their nodes, but this doesn’t matter since they are immutable there’s no danger of something changing them.

Similarly F# has immutable record types that create updated copies of them. These generally perform well as you if you’re object graph is entirely immutable you generally only need to make a shallow copy. Say a record has 4 fields, that’s just 4 references to be copied – not a lot of copying. Also if you allocation then copying in a short space of time then you’ll only every writing to the first generation of .NET garbage collector, which does a create job of cleaning them up efficiently.

Finally I’ve come to find F# immutable Set and Map structures vital for multithreaded programming. It’s great to be able to pass theses structures off to separate threads to perform some processing retrieve the results and merger them in without having to worry about locking etc.

So given all that, my general approach would be to start of immutable for clarity and easy of programming. If performance is not good enough profile careful and see where the bottles necks are. You probably won’t find that it’s the immutable types that are problematic, but if you do you can always optimize and use some mutable types in their place.

Hope that helps clarify things a bit,

Rob