Overview of common bottlenecks

F# has common bottlenecks although they might be subtle as well.

In order to be able to quickly understand the bottleneck factors in F#, we will categorize the shared general bottlenecks of .NET as managed bottlenecks (also in C#/VB), and F#-only bottlenecks (this includes when using F# with other languages).

The following are managed .NET bottlenecks (from obvious to less obvious):

• String concatenations, such as using string String.Concat instead of StringBuilder. This is often overlooked because of a lack of awareness of the string's immutability.
• Usage of non-generic collections such as ArrayList.
• Incorrectly handling side effects, such as exceptions and I/O.
• Mutable objects usage, including casting.
• Complex objects that will be serialized and deserialized, for example: sending DataSet that has DataTables over HTTP.
• Ignoring performance profiling.

Side effects mean all of the elements outside the formal computation (it is often called the outside world) that we interact with, and this includes the changing global state. The outside world can be all of the things that we cannot fully determine as the end result. Examples of the outside world include:

• I/O: This is included as being part of the outside world because you cannot determine or guarantee any kind of work you pass to I/O to be successfully completed. For example, when sending a command to a printer to print a document, we cannot guarantee 100% success of the printing operation. We cannot even guarantee that the process of sending the data to the printer will be successful or not before the printer receives the data and begins to print the document.
• Global static mutable variables: A quick example of this is when we define a public static variable in the scope of ASP.NET. Every value change will always change the condition of any user of the ASP.NET application.
• Functions or properties that always have different results when they are invoked, such as DateTime.Now.

Note

DateTime.Now will always return different results and this is as expected because the result must change every time it is called or instantiated. It is not free of side effects, but it is still expected to always return a different result.

Side effects are not just for functional programming developers, as many of us are now becoming quite aware. There are no absolute side effect-free computations because we should learn and be able to correctly handle them. For example, even printing a screen to a console is also a side effect because it involves I/O, and it changes the state of the outside world.

The following are F#'s unique bottlenecks:

• Incorrect use of data structures and collections
• Incorrect use of auto generalization and other language constructs
• Incorrectly implemented concurrency problems, such as mixing synchronous and asynchronous although the original intention is asynchronous
• Slow performance when having to interoperate with other languages' class libraries such as C#/VB
• Scaling MailboxProcessor in F#
• Identifying when tail call optimization should occur
• Slow response when resolving type in type provider implementation
• Slow performance when implementing computation workflow