F# - ValueOption suspiciously slow compared to Option and Result

[kerams]

Runnable benchmark https://github.com/kerams/oh-dear.

The test is very simple - we do a single remapping of ValueSome, Some and Ok. (MethodImpl probably has no effect here.)

[<MemoryDiagnoser>]
type Current () =

    [<MethodImpl(MethodImplOptions.NoInlining)>]
    let o = Some 10

    [<MethodImpl(MethodImplOptions.NoInlining)>]
    let vo = ValueSome 10

    [<MethodImpl(MethodImplOptions.NoInlining)>]
    let r = Result<int, string>.Ok 10

    [<Benchmark>]
    member _.Option() =
        match o with
        | Some x -> Some (x + 3)

    [<Benchmark>]
    member _.Voption() =
        match vo with
        | ValueSome x -> ValueSome (x + 3)

    [<Benchmark>]
    member _.Result() =
        match r with
        | Ok x -> Result<int, string>.Ok (x + 3)

Decompiled IL looks as expected.

[Benchmark(19, "C:\\code\\Test\\Bench\\Program.fs")]
public FSharpOption<int> Option()
{
    FSharpOption<int> fsharpOption = this.o;
    if (fsharpOption != null)
    {
        FSharpOption<int> fsharpOption2 = fsharpOption;
        int x = fsharpOption2.Value;
        return FSharpOption<int>.Some(x + 3);
    }
    throw new MatchFailureException("C:\\code\\Test\\Bench\\Program.fs", 21, 14);
}

[Benchmark(24, "C:\\code\\Test\\Bench\\Program.fs")]
public FSharpValueOption<int> Voption()
{
    FSharpValueOption<int> fsharpValueOption = this.vo;
    if (fsharpValueOption.Tag == 1)
    {
        int x = fsharpValueOption.Item;
        return FSharpValueOption<int>.NewValueSome(x + 3);
    }
    throw new MatchFailureException("C:\\code\\Test\\Bench\\Program.fs", 26, 14);
}

[Benchmark(29, "C:\\code\\Test\\Bench\\Program.fs")]
public FSharpResult<int, string> Result()
{
    FSharpResult<int, string> fsharpResult = this.r;
    if (fsharpResult.Tag == 0)
    {
        int x = fsharpResult.ResultValue;
        return FSharpResult<int, string>.NewOk(x + 3);
    }
    throw new MatchFailureException("C:\\code\\Test\\Bench\\Program.fs", 31, 14);
}

Jitted on .NET 7 on Sharplab.

Benchmark results look like this, reproducible across multiple runtimes and CPUs (all results here).

BenchmarkDotNet=v0.13.5, OS=Windows 11 (10.0.22621.1413/22H2/2022Update/SunValley2)
AMD Ryzen 9 7900, 1 CPU, 24 logical and 12 physical cores
.NET SDK=8.0.100-preview.2.23157.25
 [Host]     : .NET 8.0.0 (8.0.23.12803), X64 RyuJIT AVX2 DEBUG
 DefaultJob : .NET 8.0.0 (8.0.23.12803), X64 RyuJIT AVX2

Method	Mean	Error	StdDev	Gen0	Allocated
Option	2.0639 ns	0.0204 ns	0.0171 ns	0.0014	24 B
Voption	3.0861 ns	0.0381 ns	0.0337 ns	-	-
Result	0.2330 ns	0.0071 ns	0.0063 ns	-	-

ValueOption remapping is slower than Option despite the fact that Option needs to allocate. I'd expect performance to be at least as good as in the Result case (since the struct size of ValueOption is smaller than Result).

[En3Tho]

This should belong to runtime as it's a codegen issue. If you pick x64 on sharplab (your link points to "default" branch and it's a x86 codegen) you will see that jit generates stack spill and needless register-stack-register movs. I don't think F# is to blame here.

I wonder what .Net8 produces here. There were some struct promotion improvements but I don't remember if they were merged or not

Also, maybe Nullable'T should be included too.

[kerams]

A slightly adjusted benchmark

[<MemoryDiagnoser>]
type Current () =

    let o = Some 10

    let vo = ValueSome 10

    let r = Result<int, string>.Ok 10

    let n = System.Nullable 10

    [<MethodImpl(MethodImplOptions.NoInlining)>]
    member _.O () = o

    [<MethodImpl(MethodImplOptions.NoInlining)>]
    member _.Vo () = vo

    [<MethodImpl(MethodImplOptions.NoInlining)>]
    member _.R () = r

    [<MethodImpl(MethodImplOptions.NoInlining)>]
    member _.N () = n

    [<Benchmark>]
    member x.Option() =
        match x.O () with
        | Some x -> Some (x + 3)

    [<Benchmark>]
    member x.Voption() =
        match x.Vo () with
        | ValueSome x -> ValueSome (x + 3)

    [<Benchmark>]
    member x.Result() =
        match x.R () with
        | Ok x -> Result<int, string>.Ok (x + 3)

    [<Benchmark>]
    member x.Nullable() =
        let n = x.N ()
        if n.HasValue then System.Nullable (n.Value + 3) else System.Nullable ()

gives

BenchmarkDotNet=v0.13.5, OS=Windows 11 (10.0.22621.1413/22H2/2022Update/SunValley2)
AMD Ryzen 9 7900, 1 CPU, 24 logical and 12 physical cores
.NET SDK=8.0.100-preview.2.23157.25
  [Host]     : .NET 8.0.0 (8.0.23.12803), X64 RyuJIT AVX2 DEBUG
  DefaultJob : .NET 8.0.0 (8.0.23.12803), X64 RyuJIT AVX2

Method	Mean	Error	StdDev	Gen0	Allocated
Option	3.023 ns	0.0858 ns	0.1311 ns	0.0014	24 B
Voption	3.505 ns	0.0277 ns	0.0231 ns	-	-
Result	1.936 ns	0.0393 ns	0.0368 ns	-	-
Nullable	3.434 ns	0.0031 ns	0.0024 ns	-	-

[vzarytovskii]

@EgorBo any suggestions here? Should we create an issue for runtime to track it?

[EgorBo]

Yeah looks like a codegen issue, let's transfer it to dotnet/runtime

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Runnable benchmark https://github.com/kerams/oh-dear.

The test is very simple - we do a single remapping of ValueSome, Some and Ok. (MethodImpl probably has no effect here.)

[<MemoryDiagnoser>]
type Current () =

    [<MethodImpl(MethodImplOptions.NoInlining)>]
    let o = Some 10

    [<MethodImpl(MethodImplOptions.NoInlining)>]
    let vo = ValueSome 10

    [<MethodImpl(MethodImplOptions.NoInlining)>]
    let r = Result<int, string>.Ok 10

    [<Benchmark>]
    member _.Option() =
        match o with
        | Some x -> Some (x + 3)

    [<Benchmark>]
    member _.Voption() =
        match vo with
        | ValueSome x -> ValueSome (x + 3)

    [<Benchmark>]
    member _.Result() =
        match r with
        | Ok x -> Result<int, string>.Ok (x + 3)

Decompiled IL looks as expected.

[Benchmark(19, "C:\\code\\Test\\Bench\\Program.fs")]
public FSharpOption<int> Option()
{
    FSharpOption<int> fsharpOption = this.o;
    if (fsharpOption != null)
    {
        FSharpOption<int> fsharpOption2 = fsharpOption;
        int x = fsharpOption2.Value;
        return FSharpOption<int>.Some(x + 3);
    }
    throw new MatchFailureException("C:\\code\\Test\\Bench\\Program.fs", 21, 14);
}

[Benchmark(24, "C:\\code\\Test\\Bench\\Program.fs")]
public FSharpValueOption<int> Voption()
{
    FSharpValueOption<int> fsharpValueOption = this.vo;
    if (fsharpValueOption.Tag == 1)
    {
        int x = fsharpValueOption.Item;
        return FSharpValueOption<int>.NewValueSome(x + 3);
    }
    throw new MatchFailureException("C:\\code\\Test\\Bench\\Program.fs", 26, 14);
}

[Benchmark(29, "C:\\code\\Test\\Bench\\Program.fs")]
public FSharpResult<int, string> Result()
{
    FSharpResult<int, string> fsharpResult = this.r;
    if (fsharpResult.Tag == 0)
    {
        int x = fsharpResult.ResultValue;
        return FSharpResult<int, string>.NewOk(x + 3);
    }
    throw new MatchFailureException("C:\\code\\Test\\Bench\\Program.fs", 31, 14);
}

Jitted on .NET 7 on Sharplab.

Benchmark results look like this, reproducible across multiple runtimes and CPUs (all results here).

BenchmarkDotNet=v0.13.5, OS=Windows 11 (10.0.22621.1413/22H2/2022Update/SunValley2)
AMD Ryzen 9 7900, 1 CPU, 24 logical and 12 physical cores
.NET SDK=8.0.100-preview.2.23157.25
 [Host]     : .NET 8.0.0 (8.0.23.12803), X64 RyuJIT AVX2 DEBUG
 DefaultJob : .NET 8.0.0 (8.0.23.12803), X64 RyuJIT AVX2

Method	Mean	Error	StdDev	Gen0	Allocated
Option	2.0639 ns	0.0204 ns	0.0171 ns	0.0014	24 B
Voption	3.0861 ns	0.0381 ns	0.0337 ns	-	-
Result	0.2330 ns	0.0071 ns	0.0063 ns	-	-

ValueOption remapping is slower than Option despite the fact that Option needs to allocate. I'd expect performance to be at least as good as in the Result case (since the struct size of ValueOption is smaller than Result).

Author:	kerams
Assignees:	-
Labels:	bug, area-CodeGen-coreclr, untriaged
Milestone:	-