Non-documented slow performance of Props.Create(Expression) overload

[ok-ul-ch]

• Which Akka.Net version you are using: 1.4.13
• On which platform you are using Akka.Net: .Net Core 3.1 (both Windows and Linux)
• A list of steps to reproduce the issue: Run next benchmark code:

using Akka.Actor;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

namespace PropsCreateBenchmark
{
    class Program
    {
        static void Main(string[] args)
        {
            BenchmarkRunner.Run<PropsBenchmark>();
        }
    }

    [SimpleJob]
    public class PropsBenchmark
    {
        private static readonly string Arg = "actor arg";

        [Benchmark(Baseline = true)]
        public Props UsualProps()
        {
            var props = Props.Create<Actor>(Arg);
            return props;
        }

        [Benchmark]
        public Props ExpressionsProps()
        {
            var props = Props.Create(() => new Actor(Arg));
            return props;
        }
    }

    public class Actor : ReceiveActor
    {
        public string Arg { get; }

        public Actor(string arg)
        {
            Arg = arg;
        }
    }
}

And check results

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.18363.592 (1909/November2018Update/19H2)
Intel Core i5-8600K CPU 3.60GHz (Coffee Lake), 1 CPU, 6 logical and 6 physical cores
.NET Core SDK=5.0.100
  [Host]     : .NET Core 3.1.9 (CoreCLR 4.700.20.47201, CoreFX 4.700.20.47203), X64 RyuJIT
  DefaultJob : .NET Core 3.1.9 (CoreCLR 4.700.20.47201, CoreFX 4.700.20.47203), X64 RyuJIT

Method	Mean	Error	StdDev	Ratio	RatioSD
UsualProps	56.54 ns	1.175 ns	1.306 ns	1.00	0.00
ExpressionsProps	56,668.76 ns	1,096.394 ns	1,262.609 ns	1,002.71	31.31

As you can see from the benchmark report, creation of Props using expression is very slow and impacts performance in scenarios with a big amount of short-lived or dynamically-created actors.
Since this issue is not described in the documentation here I propose to add at least a small warning about usage of this overload.

[Aaronontheweb]

Ah, so these are the performance numbers of the Props class creation, not the creation of the actor (both methods arrive at the same data structure internally.)

Ok, we can document that - this overhead is from the lamba compiler we use to extract the actor type + constructor + arguments. I think it'd be useful for users to know that.

[to11mtm]

this overhead is from the lamba compiler we use to extract the actor type + constructor + arguments.

There may be some opportunity to improve here. In a couple different projects I've had this issue and have some code that makes a best effort to avoid .Compile() and .Convert() by parsing out any constants or passed-in variables (i.e. new MyActor(configObject.ConnectionString)) and only compiling when it's more complex (i.e. function invocation) or the happy path somehow fails.

I tried out some code I had laying around for this, We can get about 10% improvement:

Before:

Method	Mean	Error	StdDev	Ratio	RatioSD
UsualProps	53.34 ns	1.116 ns	1.371 ns	1.00	0.00
ExpressionsProps	35,067.76 ns	608.278 ns	568.984 ns	660.27	20.63

After:

Method	Mean	Error	StdDev	Ratio	RatioSD
UsualProps	56.86 ns	1.167 ns	1.249 ns	1.00	0.00
ExpressionsProps	31,757.45 ns	326.256 ns	289.217 ns	560.25	12.69

I'll make a PR with these code changes.

[to11mtm]

@mralexes #4712 has been merged in, so next release you should see some improvement on Props.Create(Expression).

[Aaronontheweb]

Closing this since it was address by @to11mtm and there's not a lot of wiggle room for speeding up the compression compiler, AFAIK. The Props flavors that don't use NewExpression will be faster but they are not type-safe.