benchmark.fs

open BenchmarkDotNet.Attributes
open BenchmarkDotNet.Configs
open BenchmarkDotNet.Environments
open BenchmarkDotNet.Jobs
open BenchmarkDotNet.Running

[<MemoryDiagnoser(displayGenColumns=false)>]
[<HideColumns("Job", "Error", "StdDev", "Median", "RatioSD")>]
type Benchmarks () =
    let x = Some 3

    [<Benchmark>]
    member _.DoSomeStuffWithOptions () =
        x
        |> Option.map ((+) 1)    // Used to allocate on the heap, now it doesn't.
        |> Option.map ((+) -1)   // Used to allocate on the heap, now it doesn't.
        |> Option.defaultValue 0

ignore <| BenchmarkRunner.Run<Benchmarks>
    (DefaultConfig.Instance
        .AddJob(Job.Default.AsBaseline().WithRuntime CoreRuntime.Core80)
        .AddJob(Job.Default.WithRuntime CoreRuntime.Core90))

gistfile1.txt

| Method                 | Runtime  | Mean      | Ratio | Allocated | Alloc Ratio |
|----------------------- |--------- |----------:|------:|----------:|------------:|
| DoSomeStuffWithOptions | .NET 8.0 | 3.8792 ns |  1.00 |      48 B |        1.00 |
| DoSomeStuffWithOptions | .NET 9.0 | 0.6274 ns |  0.16 |         - |        0.00 |

I will use this space of this gist to collect other ideas to demonstrate this:

• A meaningful example with Result , e.g. parsing and validation of dirty input. In the spirit of "railway oriented programming" from Scott W., but can of course use just plain functions instead of operators as the combinators building the pipeline.

• Mutable locals (they are replaced with heap allocated RefCell if work with them involves passing them around)

@T-Gro that‘s a great idea to collect examples here. I would also like to see examples where moving to stack can’t be done .

@T-Gro that‘s a great idea to collect examples here. I would also like to see examples where moving to stack can’t be done .

As of now, the limitation is "single IL method boundary" as far as I understand the feature.
As soon as you pass the objects (options, tuples, lists,...) to a non-inlined method, e.g. from a library, it will allocate on the heap.

The ideal candidates are samples which in the end produce a single IL method (after inlining) with "newobj" being a dominant factor.

Yeah, "side-effects" of inlining will oftentimes result in allocations being also inlined as opposed to being in their own functions. Like it happened to be the case for the Option module. We might wanna see how things are inlining in certain CEs or maybe Asyncs (I suspect it's not gonna be inlining too much).