Feedback and Issues

[MattEdwardsWaggleBee]

Hello @dadhi,

First off, thank you for creating this project! We've been testing it with our own Hyperbee.Expressions project which adds support async/await and other helpers. These all work as expected with system Compile, and we've seen great performance improvements with CompileFast. However, we've encountered a few issues during implementation, some of which we've worked around, while others remain blockers.

All the interesting cases we've found are related to lowering an async block into a state machine, similar to what Roslyn does, and then uses Microsoft's IAsyncStateMachine to deal with task continuation and completion. Below we've listed the issues, but we also have test cases in our repo in the FastExpressionCompilerTests.cs file as part of our Add Support for Fast Expression Compiler work.

We've addressed as many of these issues as we can, but we wanted to reach out to you to see if you had any insights or guidance. We're happy to open detailed issues for each of these if that would be helpful, but didn't feel right just adding several issues to your repo without context. What would be the best way to proceed?

Thank you again for your work on this library! We're excited to use it in several of our projects.

Best regards,

@bfarmer67 and @MattEdwardsWaggleBee

---

Unused Expressions

When unused expressions are introduced in the expression tree, we encountered issues. We've resolved this by cleaning up our code to avoid adding these unnecessary snippets. (We didn't actually see these issues originally, so this help us clean up our code nicely!)

// FEC throws `System.InvalidProgramException: Common Language Runtime detected an invalid program.`
// WORKAROUND: Remove the unused value from the block

public class TestClass
{
    public int Result0 = 42;
    public int Result1;
}

var variable = Variable( typeof( TestClass ), "testClass" );

var block = Block(
    [variable],
    Assign(
        variable,
        New( typeof( TestClass ) )
    ),
    Block(
        Field( variable, nameof( TestClass.Result0 ) ), // Unused
        Assign(
            Field( variable, nameof( TestClass.Result1 ) ),
            Field( variable, nameof( TestClass.Result0 ) )
        )
    ),
    Field( variable, nameof( TestClass.Result1 ) )
);

var lambda = Lambda<Func<int>>( block );
var compiledLambda = lambda.CompileFast();

Passing Ref Values to Lambda

When attempting to pass results as ref to a lambda, we ran into problems. We've implemented a workaround by assigning the result to a local variable first before passing it to the lambda.

// FEC throws `System.InvalidProgramException: Common Language Runtime detected an invalid program.`
// WORKAROUND: Assign to local variable and pass variable by ref

var callRefMethod = typeof( TestClass ).GetMethod( nameof( TestClass.MethodThatTakesARef ) );

var block = Block(
    typeof( int ),
    Call( callRefMethod!, Constant( 42 ) )
);

var lambda = Lambda<Func<int>>( block );
var compiledLambda = lambda.CompileFast();

Single-Test Switch Without a Default Case

If a switch contains only one TestValue and no default case, we get an error during conditional generation. This seems to occur even when such a structure would otherwise be valid.

// FEC throws `System.NullReferenceException: Object reference not set to an instance of an object.`

var label = Label( "label" );
var block = Block(
    Switch(
        Constant( 1 ),
        SwitchCase( Goto( label ), Constant( 1 ) ) // This gets emitted as a conditional with a null False block
    ),
    Label( label ),
    Constant( 2 )
);

var lambda = Lambda<Func<int>>( block );
var compiledLambda = lambda.CompileFast();

Switch Without Any Test Cases

If a switch contains zero test cases it throws System.ArgumentOutOfRangeException: Index was out of range.. In this case we optimized our code to avoid this scenario.

// FEC throws `System.ArgumentOutOfRangeException: Index was out of range.`
// WORKAROUND: Do not use empty cases

var block = Block(
    Switch(
        Constant( 1 ),
        []  // empty cases (no body should do this)
    ),
    Constant( 2 )
);

var lambda = Lambda<Func<int>>( block );
var compiledLambda = lambda.CompileFast();

TryCatch And Goto

When the last statement in a TryCatch block is a goto and the label is on the outside, we encounter an System.InvalidProgramException: Common Language Runtime detected an invalid program. error. We haven’t been able to find a reliable workaround for this yet.

// FEC throws `System.InvalidProgramException: Common Language Runtime detected an invalid program.`
var label = Label( "label" );
var variable = Variable( typeof( int ), "variable" );

var block = Block(
    [variable],
    TryCatch(
        Block(
            Assign( variable, Constant( 5 ) ),
            Goto( label )
        ),
        Catch(
            typeof( Exception ),
            Block(
                typeof( void ),
                Assign( variable, Constant( 10 ) )
            )
        )
    ),
    Label( label ),
    variable
);

var lambda = Lambda<Func<int>>( block );
var compiledLambda = lambda.CompileFast();

Additionally we also found that when the label is moved into the same scope as the goto we get System.ArgumentException: Bad label content in ILGenerator.

// FEC throws `System.ArgumentException: Bad label content in ILGenerator.`
var label = Label( "label" );
var variable = Parameter( typeof( int ) );
var exceptionParam = Parameter( typeof( Exception ), "ex" );

var block = Block(
    [variable],
    TryCatch(
        Block(
            Goto( label ),
            Throw( Constant( new Exception( "Exception" ) ) ),
            Label( label ),
            Assign( variable, Constant( 2 ) )
        ),
        Catch( exceptionParam, Assign( variable, Constant( 50 ) ) )
    ),
    variable
);

var lambda = Lambda<Func<int>>( block );
var compiledLambda = lambda.CompileFast();

[dadhi]

@MattEdwardsWaggleBee Hi, Matt.

Thanks for the good roundup of the potential bugs :-)

I will walk them one-by-one and will create the respective issues myself.
I will reference this discussion to keep you updated.

[dadhi]

@MattEdwardsWaggleBee Regarding the helpers for the async Expression, I had experimented with it in the past.

Here is the entry point: https://github.com/dadhi/FastExpressionCompiler/blob/f92ba2fa7ca4bb17a6ff8a7a54ea0708a4d7787e/test/FastExpressionCompiler.LightExpression.IssueTests/ObjectMethodExecutor/ObjectMethodExecutorCompiledFastClosure.cs

There are also some benchmarks there.

[MattEdwardsWaggleBee]

@dadhi I'll take a look. Thanks!

[MattEdwardsWaggleBee]

@dadhi Out of curiosity, during your investigations, did you encounter the need to build an async state machine? When we first started working on this, our initial focus was on handling await, but we realized we also needed a state machine to support building complex async expressions.

[dadhi]

@MattEdwardsWaggleBee I would say no. Here is the context for my experiments #72

[sebastienros]

Would it be helpful? https://dotnet.github.io/dotNext/features/metaprogramming/async.html

[MattEdwardsWaggleBee]

Hi @sebastienros If you are responding to us, we are aware of .NEXT. It's a great project. We looked at it, but it didn't work for our use-cases, including our desire to use FEC.

Our library works with System compile. Our performance is very good comparatively, but we aren't close to the levels possible with FEC. In the cases where we are able to use FEC, our async/await execution is very close to native speed! ❤️

Full FEC compatibility is really important to us, and we are open to any modifications that would allow us to use it. The items discussed above, are where we are experiencing some difficulty.

[dadhi]

@MattEdwardsWaggleBee

Hi, I have added the two issues #439 and #440 and did some tests and fixes for them. @wip

Btw, I am usually using the same procedure to adding the failed tests for the new issues. If you do it for the upcoming issues in the PRs, it may speedify my fixes. Thank you.

[dadhi]

#440 is fixed too

[MattEdwardsWaggleBee]

Wow, thank you so much!

[dadhi]

And now #439 is fixed too.
@MattEdwardsWaggleBee Meanwhile, did you find something new?
If not, I will sleep on the fixes and will release the new version tomorrow.

[MattEdwardsWaggleBee]

@dadhi, sort of, we ran into a case where we want to pass a lambda/Expression to something like Task.Run(), but since it only takes an action we need to pass information using closure. Currently, we're seeing a NotSupportedException, but we wanted to create a simpler use case than what we have in our code.

If you are okay, hold off for the weekend. I can get you something Monday morning.

[dadhi]

Sure. Have a nice weekend.

[dadhi]

@MattEdwardsWaggleBee I have released the v5.0.1 with fixes for this discussion and #437

[MattEdwardsWaggleBee]

@dadhi was going to say I'll take a look tomorrow, but I couldn't wait. I updated my Nugets and all my tests are passing now! We are seeing close to native speeds with our async/await library! (https://github.com/Stillpoint-Software/hyperbee.expressions)

Thank you so much for your help and your project!. ❤️

| Method                  | Mean          | Error          | StdDev        | Ratio | RatioSD | Gen0   | Gen1   | Allocated | Alloc Ratio |
|------------------------ |--------------:|---------------:|--------------:|------:|--------:|-------:|-------:|----------:|------------:|
| 'Hyperbee Fast Compile' |  32,897.72 ns |  30,307.017 ns |  1,661.230 ns |  1.00 |    0.06 | 2.1973 | 1.9531 |   10926 B |        1.00 |
| 'Hyperbee Compile'      | 327,155.97 ns | 288,646.133 ns | 15,821.669 ns |  9.96 |    0.60 | 7.3242 | 0.4883 |   35186 B |        3.22 |
|                         |               |                |               |       |         |        |        |           |             |
| 'Native Execute'        |      39.22 ns |       7.130 ns |      0.391 ns |  1.00 |    0.01 | 0.0168 |      - |      79 B |        1.00 |
| 'Hyperbee Fast Execute' |      57.99 ns |      36.158 ns |      1.982 ns |  1.48 |    0.05 | 0.0355 |      - |     167 B |        2.11 |
| 'Hyperbee Execute'      |     560.79 ns |     283.373 ns |     15.533 ns | 14.30 |    0.36 | 0.0486 |      - |     231 B |        2.92 |

[dadhi]

@MattEdwardsWaggleBee Glad to see the results. Maybe it can be tuned even more, if I understood what the complete expressions being used here.

Btw, is it a FEC LightExpression?

Also I was wondering, are you using your lib by yourself, or is it your side project?

[MattEdwardsWaggleBee]

We are planning on making more complex tests, but haven't yet. You can see the current benchmark here. Most of our usages of expressions are for rules, workflows, scripting, etc so they're not static. (e.g. we use expressions in our Json library for speedy filters)

Btw, is it a FEC LightExpression?

Not yet

Also I was wondering, are you using your lib by yourself, or is it your side project?

It's becoming a side project.😄 The company decided to open source several libraries we've built over the years. Most of the use cases are still internal repos or for clients.

[dadhi]

@MattEdwardsWaggleBee Thanks for the info.

I think AsyncBlockExpression can be further optimized.
I can imagine that pairing it with the LightExpression variant will speedup compilation making it intrinsic to the FEC.
As for the result IL I should dig deeper, if I have the time :)

Let's bookmark those possibilities here and keep this discussion around.

[MattEdwardsWaggleBee]

Any thoughts or ideas would be great. Thanks for all your help, it's made a big difference.