Welcome to FastExpressionCompiler Discussions!

[dadhi]

Welcome to the discussions 🥂

• Here you may ask questions
• Discuss the ideas
• Share your usage experience
• Thank the contributors 🙇

[aughey]

Is there an easy way to retrieve the generated IL code? I'm having an issue and could benefit from seeing the generated code.

[exyi]

There is something used in the tests, but it seems to only work on Windows...

I found that you can use dotnet dump, here is some intro how to take the memory dump: https://github.com/dotnet/diagnostics/blob/main/documentation/dotnet-dump-instructions.md

Then, in dotnet dump analyze you'll have to find the delegate object and then you should be able to use dumpil ADDR_OF_DYNAMIC_METHOD to see the IL code.

To find the object, I'd recommend making sure that the delegate is in a local variable on the stack when you are taking the dump (you can place while(true) right after the CompileFast call). Alternatively, you can look through all objects in dumpheap, it's a bit painful but with some scripting it's not that bad...

[dadhi]

Hi, see the example of diagnostics including the IL dump in the tests

FastExpressionCompiler/test/FastExpressionCompiler.IssueTests/Issue309_InvalidProgramException_with_MakeBinary_liftToNull_true.cs

Line 35 in 6aeb07d

fSys.PrintIL();

[Marluwe]

Hi there,

sorry, for this probably quite complicated question.

Do you think it is possible to merge the op codes of a method and a delegate argument?

What I mean: Compiling
list.Foo(item => item.IsRelevant) with
public static int Foo<TIn, TOut>(IEnumerable<TIn> list, Func<TIn,TOut> selector)
will create a delegate for the inner selector expression.
In case the called method "Foo" uses the selector only for evaluating it directly (not forwarding or storing it), we might take the op_code of Foo and replace all calls to selector with its op codes (in our case usually given as an Expression).
Of course, this only works if the method itself (Foo) does no need the selector in any other way than evaluating it.

A bit about the motivation:

Currently, we use an ExpressionVisitor to replace any constellation of Linq Where / Select / Count / Sum / Any / First / Last by loops where the loop uses the expressions for the selectors and perdicates.
list.Count(x => x.Prop > 3) turns into

T item = default;
for (int i = 0; i < list.Count; i++)
{
  item = list[i];
  if (item.Prop > 3) // this is where we inject the expression of the predicate into the loop
    count++;
}
return count;

Benchmarks of the compiled lambda show, that this removes any allocations and it is about 2.5 times faster (loop vs. enumeration plus no calling of delegates) (in .net9).
Another benefit is the removal of scopes. An example: list.Foo(x => x.Children.With(c => c.Prop1 > x.Prop1)) needs to create a scope such that c => c.Prop1 > x.Prop1 has access to x. If we can inject the expression for the argument, we don't need to create any delegate and hence avoid the scope.

The question won't handle the Linq cases, as those usually forward the argument to specialized iterators. But it would help us, with our own extension methods.

[dadhi]

@Marluwe Hi.

You mean to inline the predicate delegates on call-site?

To do that with FEC you need an access to the call site expression itself, e.g. to Foo method body as expression. Then you will have the normal Invoke expression of predicate lambda inside.

Both System Compile and FEC CompileFast will inline the InvocationExpression. In FEC you may modify this behavior via CompilerFlags to CompileFast, which actually disables the inlining :) Sometimes it is good to have your delegate boundaries, but not in your case.

I think, it will provide you with some initial info. We may discuss futher with more detailed example, better in form of the isolated test.

Cheers.