Book Image

F# High Performance

By : Eriawan Kusumawardhono
Book Image

F# High Performance

By: Eriawan Kusumawardhono

Overview of this book

F# is a functional programming language and is used in enterprise applications that demand high performance. It has its own unique trait: it is a functional programming language and has OOP support at the same time. This book will help you make F# applications run faster with examples you can easily break down and take into your own work. You will be able to assess the performance of the program and identify bottlenecks. Beginning with a gentle overview of concurrency features in F#, you will get to know the advanced topics of concurrency optimizations in F#, such as F# message passing agent of MailboxProcessor and further interoperation with .NET TPL. Based on this knowledge, you will be able to enhance the performance optimizations when implementing and using other F# language features. The book also covers optimization techniques by using F# best practices and F# libraries. You will learn how the concepts of concurrency and parallel programming will help in improving the performance. With this, you would be able to take advantage of multi-core processors and track memory leaks, root causes, and CPU issues. Finally, you will be able to test their applications to achieve scalability.
Table of Contents (15 chapters)
F# High Performance
Credits
About the Author
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface

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