Hyperbee.Expressions.Compiler 1.5.0

Hyperbee Expression Compiler

A high-performance, IR-based expression compiler for .NET. Drop-in replacement for Expression.Compile() that is 8-28x faster and allocates 31-52% less than the System compiler and supports all expression tree patterns.

Why Another Expression Compiler?

We ❤️ FastExpressionCompiler. FEC is faster than Hyperbee Expression Compiler, and allocates less memory - and for many workloads it's the right choice. If FEC compiles your expressions correctly, use it.

FEC's single-pass, low allocation, IL emission approach supports most, but not all, expression patterns. See FEC issues; patterns like compound assignments inside TryCatch, complex closure captures, and certain value-type operations aren't currently supported.

Hyperbee takes a middle ground: a multi-pass IR pipeline that lowers expression trees to an intermediate representation, runs optimization passes, validates structural correctness, and then emits IL. This architecture trades a small amount of speed and allocation overhead for correct IL across all expression tree patterns while significantly outperforming the System Compiler.

Performance

HEC is consistently 8-28x faster than the System Compiler and within 0.96-1.50x of FEC across all tiers - while producing correct IL for the sub-set of patterns FEC doesn't support (NegateChecked overflow, NaN comparisons, value-type instance calls, compound assignments in TryCatch, etc.).

For BlockAsync and BlockEnumerable, which FEC does not currently support, HEC compiles about twice as fast as the System compiler and the compiled coroutines run 15-19x faster.

A lambda invoked in place (Expression.Invoke( lambda, args )) is inlined at the call site, so it needs no second compilation and captures nothing. See Invoked lambdas.

The Complex tier standout (~28x vs System) is where the multi-pass IR architecture pays off against the System compiler's heavyweight compilation pipeline. The Loop tier at 1.53x is the widest gap vs FEC. Simple is the one tier where HEC compiles faster, and that is FEC 5.4.1 being slower there than 5.3.0 rather than a result of ours - read it as one tier moving in one release.

Compilation Benchmarks

BenchmarkDotNet v0.15.8, Windows 11
Intel Core i9-9980HK CPU 2.40GHz, 1 CPU, 16 logical and 8 physical cores
.NET SDK 10.0.103 - .NET 9.0.12, X64 RyuJIT x86-64-v3

20 iterations, 8 warmup, one run.

Coroutines

FEC does not support BlockAsync or BlockEnumerable. Against the System compiler:

Allocation Profile

The multi-pass IR pipeline allocates roughly 1.8–3.9× more than FEC per compilation call but 31–52% less than the System Compiler. The overhead is per-compilation, not per-execution: no compiler allocates per call.

Compiled delegates execute at equivalent speed whichever compiler produced them. HEC costs about a nanosecond more per call than the System compiler, flat across body sizes -- a property of reaching the delegate, not of the code inside it -- and sits inside FEC's own margin. See Execution Speed.

For hot paths that compile once and cache, the allocation difference is negligible. For workloads that re-compile frequently (dynamic LINQ providers, interpreted rule engines), prefer FEC when its patterns cover your use case -- unless you need coroutines, which FEC does not compile.

Execution Benchmarks

All three compilers produce delegates with equivalent runtime performance and no per-call allocation. HEC costs about a nanosecond more per call than the System compiler, flat across body sizes -- a property of reaching the delegate rather than of the code inside it -- and sits inside FEC's own margin.

Measured over a thousand calls per operation, in nanoseconds per call. Measuring one call at a time does not work here: a body like a + b runs in less time than the harness spends reaching it.

The difference is the column to read rather than a ratio. A ratio taken here is sensitive to how much loop and dispatch overhead sits in the denominator -- it is in all three numbers equally -- which inflates it on exactly the tiers where the absolute difference is smallest.

This section previously attributed the difference to JIT inlining decisions around DynamicMethod boundaries. It was not that. Delegates over a static method with nothing bound have no target for the slot Delegate.Invoke passes one in, so the runtime inserts a thunk that shifts every argument down one on the way through. Every compiled delegate is now closed over its constants array, empty when there is nothing to read, which is the shape the System compiler uses. See Execution Speed.

Compiler Comparison

Summary: Use FEC when its speed advantage matters and your expression patterns are in its comfort zone. Use Hyperbee when you need correct compilation across all patterns with near-FEC performance.

Getting Started

Installation

dotnet add package Hyperbee.Expressions.Compiler

Basic Usage

using Hyperbee.Expressions.Compiler;

// Direct compilation - drop-in replacement for Expression.Compile()
var lambda = Expression.Lambda<Func<int, int, int>>(
    Expression.Add( a, b ), a, b );

var fn = HyperbeeCompiler.Compile( lambda );
var result = fn( 1, 2 ); // 3

Extension Method

using Hyperbee.Expressions.Compiler;

var fn = lambda.CompileHyperbee();

Safe Compilation

// Returns null instead of throwing on unsupported patterns
var fn = HyperbeeCompiler.TryCompile( lambda );

// Falls back to System compiler on failure
var fn = HyperbeeCompiler.CompileWithFallback( lambda );

Compile to MethodBuilder

Emit the expression tree directly into a static MethodBuilder on a dynamic type - useful when building assemblies with AssemblyBuilder/TypeBuilder. Only expressions with embeddable constants (no closures over heap objects) are supported; use TryCompileToMethod for a non-throwing variant.

var ab = AssemblyBuilder.DefineDynamicAssembly( new AssemblyName( "MyAssembly" ), AssemblyBuilderAccess.Run );
var mb = ab.DefineDynamicModule( "MyModule" );
var tb = mb.DefineType( "MyType", TypeAttributes.Public | TypeAttributes.Class );
var method = tb.DefineMethod( "Add", MethodAttributes.Public | MethodAttributes.Static,
    typeof( int ), [typeof( int ), typeof( int )] );

var a = Expression.Parameter( typeof( int ), "a" );
var b = Expression.Parameter( typeof( int ), "b" );
HyperbeeCompiler.CompileToMethod( Expression.Lambda( Expression.Add( a, b ), a, b ), method );

var type = tb.CreateType();
var result = (int) type.GetMethod( "Add" )!.Invoke( null, [1, 2] )!; // 3

Architecture

The compiler uses a four-stage pipeline:

Expression Tree
      |
      v
  [1. Lower]         ExpressionLowerer: tree → flat IR instruction stream
      |
      v
  [2. Transform]     StackSpillPass → PeepholePass → DeadCodePass → IRValidator
      |
      v
  [3. Map]           Build constants array for non-embeddable values
      |
      v
  [4. Emit]          ILEmissionPass: IR → CIL via ILGenerator → DynamicMethod
      |
      v
    Delegate

Optimization Passes

Supported Frameworks

• .NET 8.0
• .NET 9.0
• .NET 10.0

Credits

• FastExpressionCompiler by Maksim Volkau - the inspiration and benchmark target. FEC pioneered high-performance expression compilation and remains the fastest option available. ❤️
• System.Linq.Expressions - the reference implementation and correctness baseline.

License

Licensed under the MIT License.