Comparison with Interpreted LambdaExpression?

[jods4]

Since .net 4.7.1 there's an overload LambdaExpression.Compile(bool preferInterpretation) (which I believe has no equivalent in FEC?).

When you pass preferInterpretation: true, the lambda is quickly converted into a stack-based interpreter.
It's a trade off between compilation-time (supposedly much faster) and runtime-performance (obviously slower).
The motivation is that you sometimes have an API that takes an Expression that you need to evaluate just once, or maybe a few times. In this case, the overall performance of compile + call would be better with the interpreter rather than doing a full compilation.

I think it'd be valuable to add this variant to the benchmarks, to see how it compares with FEC and might be (or not) a viable alternative for expressions evaluated only once (or few times).
Benchmarking is a tad tricky, as ideally for a one-time Expression you'd like to factor in the JIT time to native code of the compiled delegate (no warmup or repeated executions).

[dadhi]

Hi @jods4

I know about the interpretation option. This library does not cover the use of it.
It may work faster for your specific case when the Expression is need to be executed once.
The simplified math for the exec time is similar to the following:

• Let's say the lambda execution or direct method call is 1x.
• Then Expression interpretation is ~10x. It will stay the same 10x for any subsequent interpretations.
• The Expression compilation is ~1000x. But it will be 1x for the subsequent calls of the compiled delegate.

So, calculate for yourself how many calls you need to win the perf.

There is also a hybrid approach I am using for https://github.com/dadhi/DryIoc.
Basically, I am interpreting the expression on the first access, then compiling and caching the result delegate on the second access, and then using the compiled delegate on subsequent accesses.

There is also a bonus if you know the expressions - it may be faster to program your own Interpretator to avoid the reflection calls for known parts of your expression. This is done in DryIoc.

[jods4]

Thanks for your insight @dadhi !

Especially the numbers, it's really helpful. Without knowing if we're talking 1x, 10x, 100x it's impossible to make guided decisions.

As Dryloc docs mention the same 1x, 10x, and 1000x ratios, I assume we're talking FEC.
Based on your benchmark, using System.Expression for compilation would be 10'000x to 40'000x (wow... that really makes you think hard how many times you're gonna invoke that lambda).

[MariusDotNet]

I have the same consideration if to use the interpreted version or to use the FastExpressionCompiler in my project when trying to get the values of the arguments of an MethodCallExpression.

Since the argument expressions are not cached and would compile always again the interpreted version is my favourite and is sufficient in my case.

In my project I must come along still with .NET Framework 4.8. What I am wondering: In .NET 8 the intepreted version is about 10-15 times faster. But in .NET Framework 4.8 the intepreted version is even a little slower than the compiled version. Do you have an idea why this is the case?

Maybe you also have an idea how to cache the argument expressions myself with the FastExpressionCompiler...

Thanks!

[dadhi]

Hi. Interpretation uses the reflection to call methods, construct things, etc. The reflection .Invoke perf was greatly improved in the recent .Net versions. So, likely you've got your perf in Expr Interpretation for free based on the wider BCL improvements.

As of .Net 4.8 slowliness, not sure.

Regarding caching of expr, do you mean caching the expression itself or its compilation artifacts, e.g. IL?

[MariusDotNet]

Thanks dadhi for your help!

Hi. Interpretation uses the reflection to call methods, construct things, etc. The reflection .Invoke perf was greatly improved in the recent .Net versions. So, likely you've got your perf in Expr Interpretation for free based on the wider BCL improvements.

Yes, this sound plausible.

Regarding caching of expr, do you mean caching the expression itself or its compilation artifacts, e.g. IL?

So what I want to a achieve? In short I want to serialize the calls of interface methods and it argument values (the condition is that the values are serializable) without really calling the implementation (which is not even available). I guess expressions are the most suitable way to do that (?).

Sample:

internal interface IMyInterface
{
    int Foo(object a);
}
...
var value2 = 3;
SerializeCall((IMyInterface interf) => interf.Foo(value2));

I serialize the arguments like this:

private static void SerializeCall<INTERFACE>(Expression<Action<INTERFACE>> expr)
{
    var methodCallExpr = ((MethodCallExpression)expr.Body);
    ...
    // Extract argument values
    var argumentValues = methodCallExpr.Arguments
        .Select((arg, index) => Expression.Convert(arg, typeof(object)))
        .Select(argExpr => Expression.Lambda<Func<object>>(argExpr, null))
        .Select(funcExpr => funcExpr.CompileFast())
        .Select(func => func())
        .ToArray();
}

For optimization I would like to keep the compiled results in a dictionary. The issue here is that the expression can not be compared for equality and has not HashCode implementation. In a first approach I used the ToExpressionString() method. But I am not sure if this is safe. ToExpressionString seems to be provided only for debug purposes...

private static readonly Dictionary<string, Func<object>> cachedCompiledArgumentFunctions = new Dictionary<string, Func<object>>();

private static void SerializeCall<INTERFACE>(Expression<Action<INTERFACE>> expr)
{
    var methodCallExpr = ((MethodCallExpression)expr.Body);
   ...
    // Extract argument values
    var argumentValues = methodCallExpr.Arguments
        .Select((arg, index) => Expression.Convert(arg, typeof(object)))
        .Select(argExpr => Expression.Lambda<Func<object>>(argExpr, null))
        .Select(funcExpr =>
        {
            var funcExprString = funcExpr.ToExpressionString();
            Func<object> func;
            if (!cachedCompiledArgumentFunctions.TryGetValue(funcExprString, out func))
            {
                func= funcExpr.CompileFast();
                cachedCompiledArgumentFunctions[funcExprString] = func;
            }
            return func;
        })
        .Select(func => func())
        .ToArray();
}

[dadhi]

Huh. Ok. I have a similar thing in mind for adding espression equality #431

Regarding the Hash, I did not think about that because internally I may use Reference for the hashing. Which won't work in your scenario.

So, this is great to know. I may add hashing now to pair it with equality.

Also it may open up other opportunities. E.g. there are content addressed ASTs in the world (see https://www.unison-lang.org/ or https://eyg.run/) which enable new ways to pass code across the service boundaries, avoid recompilation, etc.

Actually, I am amazed how having the almost complete package of the compilation tooling makes possible to do new things #433, #435