Forem: Steve

Satori GC: High Throughput, Low Latency, and a Small Memory Footprint

Steve — Mon, 09 Mar 2026 17:40:49 +0000

Introduction

GC design has always had to wrestle with a hard trade-off: high throughput, low latency, and low memory usage are usually difficult to get at the same time.

Traditional approaches usually improve one side by paying somewhere else. If you want shorter pauses, you typically move more work into concurrent phases, and sometimes make ordinary object access more expensive. If you want higher throughput, you usually try to keep the steady-state fast path as cheap as possible, which means more work gets pushed into collection time. And if you want lower memory usage, you need to reclaim, compact, and return memory more aggressively.

What makes .NET's Satori GC interesting is not that it pushes one of those familiar strategies to the extreme. It starts by asking a different question: does the most frequent part of collection really have to be a global problem?

What a GC Actually Does

For a managed runtime, the GC's job is conceptually simple:

Find the objects that are still alive
Reclaim objects that are no longer reachable
Move live objects when necessary to reduce fragmentation and keep allocation efficient

The third part is where things get complicated. Once objects move, every reference to them has to stay correct. To make that possible, the GC has to pause user threads at certain points. That whole-program pause is what we usually call STW.

Generations

The reason a GC does not have to scan the entire heap every time is that it leans on a very practical observation: most objects die young.

That is why modern GCs are usually generational:

Gen 0: newly allocated objects, and the ones most likely to die quickly
Gen 1: objects that survived a few collections, but are not really old yet
Gen 2: long-lived objects that have already proven they tend to stick around

The point of generations is to keep the most frequent collections focused on the youngest part of the heap. If most short-lived objects die in Gen 0, most GC cycles never need to touch older objects at all.

Write Barriers and Card Tables

Generational GC has another crucial problem to solve: old objects can reference young objects.

If the next collection only reclaims Gen 0, but the GC does not know that some Gen 2 object contains a reference into Gen 0, it could mistakenly collect an object that is still live.

So the runtime needs an incremental way to record those updates. The common solution looks like this:

When the program writes an object reference, it also performs a tiny extra action called a write barrier
The runtime marks the relevant memory area as worth rechecking later, typically through a card table

That lets the GC avoid rescanning the entire older generation during a young-generation collection. It only needs to inspect the areas that were dirtied by the write barrier.

The Impossible Triangle

The painful part of GC design is that high throughput, low latency, and low memory usage are constantly pulling against each other.

If you optimize for low latency, you usually move more work into concurrent phases so the application and the GC can run at the same time. But concurrency is not free. To keep things correct, you often need more complicated barriers, stricter invariants, and sometimes more extra space.

If you optimize for throughput, you usually want the everyday path to stay as cheap as possible. Allocating an object, reading a reference, and updating a reference should not all carry a heavy tax. The downside is that if you avoid paying much during normal execution, more work piles up for collection time, and pauses can get longer.

If you optimize for low memory usage, you typically need to collect, compact, and release memory more aggressively. But those actions also consume time and resources.

So in a real sense, every GC is answering the same question: where do I want to pay the cost?

What Satori Is Trying to Do

Satori is not a toy collector detached from the real .NET runtime. It plugs into the actual runtime interfaces, which means it is trying to reorganize collection under real constraints, not in a simplified laboratory model.

Its goals are straightforward:

Minimize tuning, and ideally adapt automatically to the workload
Avoid long pauses
Stay fully usable under real-world feature constraints

That last point matters. A GC can look elegant if it simply deletes all the hard parts. Satori does not do that. It still has to support internal pointers, finalizers, weak references, dependent handles, collectible types, precise root scanning, and conservative root scanning.

In other words, Satori is not dodging real-world scenarios. It is reorganizing GC work while still living in the real world.

Page, Region, and Generations

Satori organizes the heap around two core abstractions: Page and Region.

Page: a larger reservation unit
Region: a smaller unit inside a Page, better suited to independent management

A single Page can contain many Regions, which gives the GC a much finer-grained unit to reason about.

Region is especially important in Satori, because it is not just a physical subdivision of the heap. It is also the:

Allocation unit
Thread-local ownership unit
Local Gen 0 collection unit
Planning unit for relocation and compaction
Unit used when reclaiming and returning free memory

Many GCs split the heap into smaller pieces, but those pieces are often mostly scheduling conveniences. In Satori, Region is a core abstraction.

Satori also keeps compact metadata around Page and Region. A Page contains structures such as a card table, a Region map, and coarser-grained card-group information. A Region contains bitmaps that record important object state, such as whether an object is marked, has escaped, or is pinned. That metadata is what makes thread-local collection, escape tracking, and local compaction practical later on.

Turning Gen 0 into a Local Problem

Satori's most important idea can be summarized in one sentence: if a batch of newly allocated objects mostly exists for a short time on a single thread, why should collecting them require stopping the world?

Satori still uses per-thread fast allocation contexts for small-object allocation, so the normal allocation path remains direct. But it adds an important twist: threads do not simply grab space from a global heap whenever they need it. They try to allocate within Regions they already own.

If the current Region still has space, allocation just continues. If the Region is nearly full, Satori's first reaction is not "this chunk is exhausted, hand it to global GC and fetch a new one." It first asks whether that Region is a good candidate for local cleanup.

That is based on a pattern that shows up constantly in real programs:

The objects were just created
Their lifetimes are short
They mostly stay within the current thread

If a Region looks like that, collecting it does not need to become a global problem. The current thread can perform a limited Gen 0 collection for that Region by itself. That is Satori's thread-local Gen 0.

An ordinary Gen 0 collection still thinks in whole-process terms: what are all the threads doing, where can old objects point into young ones, which card tables need to be scanned, and which global structures need to be synchronized?

Satori's thread-local Gen 0 shrinks the problem down to:

Which objects the current thread still holds on its own stack
Which objects in the current Region have established relationships with the outside world

That smaller scope is what makes local collection realistic.

Escape Tracking

Satori uses escape tracking to decide whether a Region can continue behaving like a thread-local one.

An object may start out thread-local and later escape. For example, it might:

Be stored in a global cache
Be attached to an object another thread can reach
Be queued as work that another thread will process later

Once that happens, the object is no longer purely local to the thread. It now has an external connection. That is what escape means here.

Thread-local collection only pays off if most of the objects in a Region really do remain local to the current thread. If more and more objects escape, the Region loses that locality, and local collection becomes less attractive.

So Satori does not pretend thread-locality lasts forever. It tracks escape explicitly. Once an object escapes, Satori records more than just that object. It also follows that object's references within the current Region, so anything in the Region that is reachable through the escaped object is accounted for too.

If only a small number of objects escape, thread-local collection can still be well worth doing, because the Region is still mostly owned by one thread. The real question is what to do when escape becomes common.

Satori uses a practical threshold: once escape grows beyond a certain point, the Region is no longer treated as thread-local Gen 0. It gets moved into more global generational management instead.

That threshold is there for a good reason:

If the collector gave up on thread-local Gen 0 at the first sign of escape, it would lose many cases where local collection is still a big win
If it insisted on thread-local Gen 0 no matter how much escape occurred, local collection would become less and less worthwhile

Satori aims for the balance point between those two extremes.

Thread-Local Collection

Once you understand thread-local Regions and escape tracking, the thread-local collection itself makes more sense.

It has a chance to be fast not because it magically does less work in the abstract, but because it works over a much smaller scope with a much smaller root set.

1. Decide Whether Collection Is Worth It

Satori does not immediately run a local collection the moment space gets tight. It first decides whether doing so is likely to pay off. For example:

Was the last local collection too recent?
Has escape already become too high?
Has the surviving data in this Region already grown too large for a small local cleanup to be attractive?

If those signals suggest the local collection would not be a good trade, Satori skips it and lets a more global path take over.

2. Mark from a Much Smaller Root Set

If the Region is still a good fit for thread-local collection, the root set is quite limited. It mainly consists of:

Objects on the current thread's stack that still point into that Region
Objects that have already escaped, plus the objects reachable from them within the Region

That is very different from a global Gen 0 collection. A global Gen 0 has to reason about all managed threads, references from older generations into younger ones, and a variety of global structures. Thread-local collection only has to look at the current thread's stack and the already-escaped part of the object graph inside the current Region.

3. Plan Compaction

After marking live objects, the job still is not finished, because the Region may now contain many holes.

At that point, Satori decides:

Which objects are still live
Where those live objects should move to make the layout denser
Which references will need to be updated afterward

Conceptually, this is the planning phase: figure out what survives, where it should go, and which references need rewriting.

4. Update References and Compact Locally

Only then does the actual compaction happen. If objects move to a denser layout, every reference to them has to be updated as well. Once that is done, the Region becomes contiguous again, and future allocation stays smooth.

And importantly, Satori is compacting a small Region, not the whole heap. That is why it has a real shot at keeping pauses small.

A Simple Example

Imagine a web request being handled on thread A. Processing that request creates a lot of short-lived objects: request context data, route-matching results, temporary parse structures, short-lived strings, and a few temporary lists.

In Satori, those objects will likely be allocated into a Region currently owned by thread A.

If the request finishes and none of those objects gets stored into a global cache or handed off to another thread, then when space in that Region starts running low, thread A can simply perform a local collection, reclaim the dead objects, and keep allocating in the same Region.

If some objects are published to a global cache, or packaged into work that gets handed to the thread pool, then those objects have escaped.

If only a small amount of that happens, Satori can still preserve the Region's thread-local character, because most of the Region is still primarily used by thread A. But if that sharing keeps growing and escape crosses the threshold, the Region is no longer a good fit for thread-local Gen 0. It leaves that private state and moves onto the more global GC path.

That is the basic strategy: solve the problem locally when locality still exists, and fall back to the global path as soon as locality stops being true.

Global GC

Satori is not only a thread-local collector. It also has a full global GC pipeline to handle cases such as:

Regions with heavy escape
Older objects
Global memory pressure
Relocation and compaction across Regions

The point is not to do only local collection. The point is to pull the most frequent and most localizable work out of the global path first, and leave genuinely global work to the global collector.

Global GC Phases

A global GC still has to do the familiar jobs:

Mark the objects that are still alive
Decide which Regions are worth compacting and which are worth moving
Update references
Move and compact when needed

Satori's goal is not to erase those phases. It is to let as much of that work as possible happen concurrently with the application. It is not chasing an absolute promise of zero pauses. It is trying to avoid piling heap-size-dependent work into a blocking phase whenever possible.

Optional Relocation

This is where the philosophical difference between Satori and another class of low-latency collectors becomes easier to see.

Some ultra-low-pause GCs keep pause times very stable because they are willing to pay a higher steady-state cost in exchange for making objects concurrently movable at almost any time. In other words, ordinary execution has to live under stronger rules all the time.

Satori does not take that route by default. It treats relocation and compaction as important, but it does not require unconditional concurrent relocation as a universal rule. Relocation at the Region level is an optional capability, not an always-on mandate.

The trade-off is fairly clear:

If you insist that any object must be movable concurrently at any moment, the normal execution path usually gets more expensive
If you treat relocation as something you do when needed, the normal execution path has a better chance to stay cheap

Satori chooses the second option. That is one of the reasons it can preserve throughput.

Letting Application Threads Help Advance Collection

Satori also includes a very practical idea: application threads can help advance collection work.

If the program allocates memory extremely quickly while concurrent GC work is not keeping up, garbage will accumulate. If that gap grows too large, the runtime may end up needing a heavy blocking phase just to catch up.

Satori's answer is simple: when it detects that risk, the threads doing allocation will also perform a bit of GC progress work themselves.

That has two benefits:

It keeps allocation from completely outrunning collection
It reduces the chance that the runtime has to recover with one large pause at the end

So Satori is not spreading concurrency overhead evenly across every object access. It prefers to ask application threads for extra help when things are actually at risk of falling behind. That is one of the key techniques it uses to balance throughput and low latency.

Low Memory Usage

Low-latency GCs often consume more memory, and that is not surprising. Keeping pauses short usually means:

More concurrent phases
More buffering
More conservative memory reservation
More metadata to coordinate correctness

Satori has a chance to keep memory usage down because it is not only rethinking how collection works. It is also attacking the problem from three directions at once.

1. Let Short-Lived Garbage Die Young

If an object only exists briefly on one thread, the ideal outcome is for it to die in thread-local collection before it ever ages into an older generation.

That directly helps in two ways:

Older generations do not get polluted with large amounts of short-lived garbage
Later global GC cycles have less surviving data to scan, move, and compact

The thread-local Gen 0 mechanism is already laying the groundwork for a smaller memory footprint.

2. Explicitly Return Free Memory to the OS

Satori also includes a dedicated thread whose job is to consolidate free Regions and return memory.

It is not the main collection engine. Its job is more practical than that:

Identify Regions that are empty enough to reclaim
Try to merge adjacent free Regions
Return memory that no longer needs to stay committed back to the operating system

More importantly, it does this in a rate-limited way. It controls how aggressively it scans and returns memory so the system does not end up thrashing just to save a little footprint.

3. Keep Metadata Overhead Under Control

The GC has to manage more than just objects. It also carries a lot of auxiliary state. If that metadata grows without restraint, overall memory usage can still look bad even if object reclamation is otherwise efficient.

Satori has a neat trick here: on 64-bit systems, it tries to reuse space near the object header that would otherwise be underutilized for temporary information, such as linkage needed during local compaction or forwarding information after relocation, instead of immediately allocating large side tables for everything.

Solving the Triangle: High Throughput, Low Latency, and Low Memory Usage

Once you put the pieces together, Satori's logic becomes much easier to see.

Why It Can Deliver Low Latency

Because it turns the most frequent young-object collection from a global coordination problem into a thread-local one.

As long as objects mostly stay on the thread that created them, a collection only needs to reason about one small Region, that thread's own stack, and a limited set of already-escaped objects, instead of stopping all managed threads to cooperate.

Why It Can Deliver High Throughput

Because it does not start by making every object access more expensive.

Satori's main strategy is:

Localize the most common short-lived garbage first
Use concurrent global GC plus mutator assistance to absorb larger pressure

Local collection also reduces the chance that short-lived garbage gets promoted into older generations. That, in turn, reduces later scanning and compaction pressure, which helps throughput too.

Why It Can Also Deliver Low Memory Usage

Because it is not relying on one trick. It combines several effects:

Let short-lived garbage die earlier, before it pollutes older generations
Explicitly return unused committed memory
Keep metadata from ballooning

So Satori's small memory footprint is not the result of one isolated optimization. It is the outcome of the whole design working together.

How It Compares with Other GCs

When comparing GC designs, the most important question is usually not which collector won a specific benchmark. It is where each collector chooses to pay its costs.

Workstation GC and Server GC

These two are variations on the same architectural line, not two completely unrelated algorithms.

Both are generational collectors. Both rely on write barriers and card tables to track references from older objects into younger ones. The small object heap is still structured as Gen 0, Gen 1, and Gen 2, and older-generation collection still involves heavier marking, planning, and compaction work.

Workstation GC is better suited to lighter, more interactive scenarios. Its characteristics include:

A more single-heap-oriented design and more restrained resource usage
Gen 0 and Gen 1 still happening as foreground STW collections
Gen 2 being able to run in the background, but with limited overall parallelism

Its strengths are maturity and relatively conservative resource usage. Its downside is also clear: under high concurrency and high allocation rates, the throughput ceiling shows up earlier.

Server GC keeps the same basic model but turns up the parallelism. It provisions separate heaps and stronger GC-thread resources for each logical processor, which makes it a better fit for server workloads. The trade-offs are usually:

Larger heaps
More threads
Heavier overall resource usage

But the key common point remains: the most frequent Gen 0 and Gen 1 collections are still fundamentally part of the global STW path. The biggest difference with Satori is that Satori attacks that hottest path first.

DATAS

DATAS is not a brand-new GC architecture. It is a policy layer on top of the existing Server GC.

It is trying to answer questions such as:

How much heap budget should this application get?
How many heaps should it use?
How should Gen 0 growth be controlled?
How can heap size better track the true volume of long-lived data?

So DATAS changes policy, not mechanism. It makes the existing Server GC smarter, but it does not change the fact that the most frequent young-generation collection still runs on the global path.

Satori is addressing a different question: can the hottest young-object collection avoid becoming a global operation in the first place?

G1

G1 also manages the heap in Regions, but it uses them for a different purpose than Satori does.

G1's core model is:

Split the heap into many fixed-size Regions
Use cross-Region reference tracking to record references between Regions
Use snapshot-style concurrent marking and write barriers to support concurrent marking
Copy surviving objects out of Regions selected for collection

In other words, G1's Regions primarily serve global balancing and pause-time control. Which Regions enter the collection set, which take part in mixed collection, and which participate in object copying are all driven by global scheduling.

Satori also uses Region, but it pushes the abstraction further. A Region is not just a scheduling unit. It is also the boundary for thread-local ownership, escape tracking, and local collection. That is the biggest philosophical difference between Satori and G1.

ZGC and Shenandoah

These low-latency collectors choose a different route.

What they have in common is that they are willing to pay for stronger runtime machinery on the normal execution path in exchange for more stable concurrent relocation. But the exact mechanisms are different.

ZGC's core design encodes some GC state directly into pointers and pairs that with read barriers. Generational ZGC adds more write-time barrier machinery on top. The goal is very clear: make concurrent relocation the default so STW time does not grow with heap size.

Shenandoah is closer to object indirection plus concurrent evacuation and compaction. It maintains an extra level of indirection per object to support concurrent relocation. Its cost profile is not identical to ZGC's, but the principle is similar: stronger runtime machinery in exchange for stronger low-pause behavior.

Satori does not take that route by default. It does not assume objects must always be movable concurrently. Instead, it makes relocation optional and localizes the hottest Gen 0 collections. That means it does not need to pay, by default, for an extra check on every object read the way ZGC does, or an extra level of indirection on every object the way Shenandoah does.

So the difference between Satori and collectors like ZGC or Shenandoah is not really about which one is more aggressive. It is about where the cost gets paid: on ordinary access paths, or in how the collector structures and scopes reclamation.

Conclusion

What makes Satori interesting is not simply that it is a concurrent GC. The more interesting point is that it rethinks how the most frequent part of collection should work.

Its core idea can be condensed into four lines:

Keep short-lived objects local whenever possible
Fall back to the global path quickly once objects start being broadly shared
Keep global GC as concurrent as possible without forcing every ordinary execution path to pay for always-on relocation
Keep memory usage low not just through faster reclamation, but also through active memory return and disciplined metadata design

If this direction matures, the significance may be larger than just "one more experimental GC." It could give .NET a meaningfully different direction for GC design.

TypedSql: Turning the C# Type System into a High-Performance SQL Query Engine

Steve — Sun, 23 Nov 2025 16:49:43 +0000

0. Introduction

TypedSql started from a very practical annoyance.

Most of the time when I write “queries” in .NET, my data is already in memory.

I have an array or a List<T>. I just want to filter and project it.

Sure, I can:

write a foreach loop — fast, explicit, but a little noisy
use LINQ — nice to read, but with iterator/delegate overhead
or, in extreme cases, push everything into a database and write real SQL

TypedSql explores a different route:

What if we treated the C# type system itself as the query plan?

Instead of:

building an expression tree at runtime, and
interpreting it over the data,

we compile a SQL‑like string into a closed generic type that describes the whole pipeline, and then run that pipeline entirely through static methods.

1. Design: queries as nested generic types

The central idea of TypedSql is deceptively simple:

A query is a nested generic type like WhereSelect<TRow, …, Stop<...>>.

That leads to a few concrete design decisions.

1.1 Execution plan in the type system

In TypedSql, every compiled query becomes a closed generic pipeline type. The building blocks are:

Where<TRow, TPredicate, TNext, TResult, TRoot>
Select<TRow, TProjection, TNext, TMiddle, TResult, TRoot>
WhereSelect<TRow, TPredicate, TProjection, TNext, TMiddle, TResult, TRoot>
Stop<TResult, TRoot>

Each of these implements:

internal interface IQueryNode<TRow, TResult, TRoot>
{
    static abstract void Run(ReadOnlySpan<TRow> rows, scoped ref QueryRuntime<TResult> runtime);

    static abstract void Process(in TRow row, scoped ref QueryRuntime<TResult> runtime);
}

Run is the outer loop, Process is the per‑row logic.

For example, the Where node looks like this:

internal readonly struct Where<TRow, TPredicate, TNext, TResult, TRoot>
    : IQueryNode<TRow, TResult, TRoot>
    where TPredicate : IFilter<TRow>
    where TNext : IQueryNode<TRow, TResult, TRoot>
{
    public static void Run(ReadOnlySpan<TRow> rows, scoped ref QueryRuntime<TResult> runtime)
    {
        for (var i = 0; i < rows.Length; i++)
        {
            Process(in rows[i], ref runtime);
        }
    }

    public static void Process(in TRow row, scoped ref QueryRuntime<TResult> runtime)
    {
        if (TPredicate.Evaluate(in row))
        {
            TNext.Process(in row, ref runtime);
        }
    }
}

The important part:

The shape of the pipeline lives entirely in the type arguments.
Each node is a struct with only static methods — no instances, no virtual calls.

From the JIT’s perspective, once the generic type is fixed, this is just a static call graph.

1.2 Columns and projections as value types

Queries run over some row type TRow that you define (a record, class, struct…).

Columns implement:

internal interface IColumn<TRow, TValue>
{
    static abstract string Identifier { get; }

    static abstract TValue Get(in TRow row);
}

For example:

internal readonly struct PersonNameColumn : IColumn<Person, string>
{
    public static string Identifier => "Name";

    public static string Get(in Person row) => row.Name;
}

Projections implement:

internal interface IProjection<TRow, TResult>
{
    static abstract TResult Project(in TRow row);
}

A simple “project a column” implementation is:

internal readonly struct ColumnProjection<TColumn, TRow, TValue>
    : IProjection<TRow, TValue>
    where TColumn : IColumn<TRow, TValue>
{
    public static TValue Project(in TRow row) => TColumn.Get(row);
}

For multiple selected columns, TypedSql uses specialized projections that construct ValueTuples:

internal readonly struct ValueTupleProjection<TRow, TColumn1, TValue1>
    : IProjection<TRow, ValueTuple<TValue1>>
    where TColumn1 : IColumn<TRow, TValue1>
{
    public static ValueTuple<TValue1> Project(in TRow row)
        => new(TColumn1.Get(row));
}

// … up to 7 columns, and then a recursive “Rest” projected by another IProjection

Again, everything is static and struct‑based.

1.3 Filters as static structs

Filters implement:

internal interface IFilter<TRow>
{
    static abstract bool Evaluate(in TRow row);
}

Comparison filters combine a column and a literal:

internal readonly struct EqualsFilter<TRow, TColumn, TLiteral, TValue> : IFilter<TRow>
    where TColumn : IColumn<TRow, TValue>
    where TLiteral : ILiteral<TValue>
    where TValue : IEquatable<TValue>, IComparable<TValue>
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static bool Evaluate(in TRow row)
    {
        if (typeof(TValue).IsValueType)
        {
            return TColumn.Get(row).Equals(TLiteral.Value);
        }
        else
        {
            var left = TColumn.Get(row);
            var right = TLiteral.Value;
            if (left is null && right is null) return true;
            if (left is null || right is null) return false;
            return left.Equals(right);
        }
    }
}

Here we handle null differently depending on whether TValue is a value type or a reference type. .NET’s JIT can recognize this pattern and specialize it for each case, generating separate code paths for value types and reference types, so in practice there is no real branching overhead.

Similarly for GreaterThanFilter, LessThanFilter, GreaterOrEqualFilter, LessOrEqualFilter, NotEqualFilter.

Boolean composition is also done at the type level:

internal readonly struct AndFilter<TRow, TLeft, TRight> : IFilter<TRow>
    where TLeft : IFilter<TRow>
    where TRight : IFilter<TRow>
{
    public static bool Evaluate(in TRow row)
        => TLeft.Evaluate(in row) && TRight.Evaluate(in row);
}

internal readonly struct OrFilter<TRow, TLeft, TRight> : IFilter<TRow>
    where TLeft : IFilter<TRow>
    where TRight : IFilter<TRow>
{
    public static bool Evaluate(in TRow row)
        => TLeft.Evaluate(in row) || TRight.Evaluate(in row);
}

internal readonly struct NotFilter<TRow, TPredicate> : IFilter<TRow>
    where TPredicate : IFilter<TRow>
{
    public static bool Evaluate(in TRow row)
        => !TPredicate.Evaluate(in row);
}

So a WHERE clause ends up as a tree of generic filter types, each with a static Evaluate.

1.4 Special handling for strings: `ValueString`

In .NET, string is a reference type, which creates some friction for TypedSql: the runtime uses generic sharing for reference types (including string), so you end up paying a small but non‑zero cost for dictionary lookups on generic instantiations. TypedSql tries to keep the hot path as value‑type‑only as possible.

To that end, it wraps strings in a small value type:

internal readonly struct ValueString(string? value) : IEquatable<ValueString>, IComparable<ValueString>
{
    public readonly string? Value = value;

    public int CompareTo(ValueString other)
        => string.Compare(Value, other.Value, StringComparison.Ordinal);

    public bool Equals(ValueString other)
    {
        return string.Equals(Value, other.Value, StringComparison.Ordinal);
    }

    public override string? ToString() => Value;

    public static implicit operator ValueString(string value) => new(value);

    public static implicit operator string?(ValueString value) => value.Value;
}

And it adapts string columns using ValueStringColumn:

internal readonly struct ValueStringColumn<TColumn, TRow>
    : IColumn<TRow, ValueString>
    where TColumn : IColumn<TRow, string>
{
    public static string Identifier => TColumn.Identifier;

    public static ValueString Get(in TRow row)
        => new(TColumn.Get(in row));
}

Internally, all string columns are normalized to ValueString, which has a couple of benefits:

the hot path stays as much value‑type‑only as possible, reducing generic‑sharing overhead
string comparisons are consistently ordinal and easy for the JIT to optimize
ValueString still converts to/from string implicitly, so the API surface remains ergonomic

2. Parsing a small SQL dialect

TypedSql supports a deliberately small SQL subset that’s tuned for single‑table, in‑memory querying:

SELECT * FROM $
SELECT col FROM $
SELECT col1, col2, ... FROM $
WHERE with:
- comparison: =, !=, >, <, >=, <=
- boolean: AND, OR, NOT
- parentheses
literals:
- integers (e.g., 42)
- floats (e.g., 123.45)
- booleans (true, false)
- single‑quoted strings ('Seattle', '' inside as escape)
- null
column names are case‑insensitive
$ is a placeholder for “the current row source”

The parser does:

Tokenization of the input SQL.
Construction of a small AST:
- ParsedQuery — selection + optional where
- Selection — SelectAll or a list of column identifiers
- WhereExpression — one of:
  - ComparisonExpression
  - AndExpression
  - OrExpression
  - NotExpression
- LiteralValue — stores both Kind and the actual value:
  - LiteralKind.Integer + IntValue
  - LiteralKind.Float + FloatValue
  - LiteralKind.Boolean + BoolValue
  - LiteralKind.String + StringValue (as string?)
  - LiteralKind.Null

At this stage, there’s no knowledge of C# types or columns — it’s just SQL structure.

Type checking and “does this literal make sense for that column?” is done later, during compilation.

3. Literals as types — including string literals

One of the distinctive features of TypedSql is that literals are represented as types, not just values.

All literal types implement:

internal interface ILiteral<T>
{
    static abstract T Value { get; }
}

This applies to:

integers (int)
floats (float)
characters (char)
booleans (bool)
strings (ValueString, wrapping string?)

3.1 Hex digits and numeric literals

Numeric literals are encoded using hex digits and bit operations.

First, there’s an IHex interface and Hex0–HexF struct types:

internal interface IHex { static abstract int Value { get; } }

internal readonly struct Hex0 : IHex { public static int Value => 0; }
// ...
internal readonly struct HexF : IHex { public static int Value => 15; }

Then, integers:

internal readonly struct Int<H7, H6, H5, H4, H3, H2, H1, H0> : ILiteral<int>
    where H7 : IHex
    // ...
    where H0 : IHex
{
    public static int Value
        => (H7.Value << 28)
         | (H6.Value << 24)
         | (H5.Value << 20)
         | (H4.Value << 16)
         | (H3.Value << 12)
         | (H2.Value <<  8)
         | (H1.Value <<  4)
         |  H0.Value;
}

Floats use the same eight‑nibble pattern but bit‑cast back to float:

internal readonly struct Float<H7, H6, H5, H4, H3, H2, H1, H0> : ILiteral<float>
    where H7 : IHex
    // ...
{
    public static float Value
        => Unsafe.BitCast<int, float>(
               (H7.Value << 28)
             | (H6.Value << 24)
             | (H5.Value << 20)
             | (H4.Value << 16)
             | (H3.Value << 12)
             | (H2.Value <<  8)
             | (H1.Value <<  4)
             |  H0.Value);
}

Characters (char) are four hex digits:

internal readonly struct Char<H3, H2, H1, H0> : ILiteral<char>
    where H3 : IHex
    // ...
{
    public static char Value
        => (char)((H3.Value << 12)
                | (H2.Value <<  8)
                | (H1.Value <<  4)
                |  H0.Value);
}

3.2 String literals: type‑level linked lists

String literals are more interesting.

TypedSql builds them out of a type‑level linked list of characters, described by IStringNode:

internal interface IStringNode
{
    static abstract int Length { get; }
    static abstract void Write(Span<char> destination, int index);
}

There are three implementations:

StringEnd — represents the end of the string (length 0)
StringNull — represents a null string (length -1)
StringNode<TChar, TNext> — one character plus the rest

internal readonly struct StringEnd : IStringNode
{
    public static int Length => 0;
    public static void Write(Span<char> destination, int index) { }
}

internal readonly struct StringNull : IStringNode
{
    public static int Length => -1;
    public static void Write(Span<char> destination, int index) { }
}

internal readonly struct StringNode<TChar, TNext> : IStringNode
    where TChar : ILiteral<char>
    where TNext : IStringNode
{
    public static int Length => 1 + TNext.Length;

    public static void Write(Span<char> destination, int index)
    {
        destination[index] = TChar.Value;
        TNext.Write(destination, index + 1);
    }
}

Now, given an IStringNode implementation, we can build a ValueString via:

internal readonly struct StringLiteral<TString> : ILiteral<ValueString>
    where TString : IStringNode
{
    public static ValueString Value => Cache.Value;

    private static class Cache
    {
        public static readonly ValueString Value = Build();

        private static ValueString Build()
        {
            var length = TString.Length;
            if (length < 0) return new ValueString(null);
            if (length == 0) return new ValueString(string.Empty);

            var chars = new char[length];
            TString.Write(chars.AsSpan(), 0);
            return new string(chars, 0, length);
        }
    }
}

So StringLiteral<TString> is an ILiteral<ValueString> whose Value is computed once, statically.

3.2.1 How a string becomes a type

The factory LiteralTypeFactory.CreateStringLiteral handles string literals:

public static Type CreateStringLiteral(string? value)
{
    if (value is null)
    {
        return typeof(StringLiteral<StringNull>);
    }

    var type = typeof(StringEnd);
    for (var i = value.Length - 1; i >= 0; i--)
    {
        var charType = CreateCharType(value[i]); // Char<...>
        type = typeof(StringNode<,>).MakeGenericType(charType, type);
    }

    return typeof(StringLiteral<>).MakeGenericType(type);
}

Let’s walk through an example: the literal 'Seattle'.

Parse phase sees 'Seattle' and produces a LiteralValue with:
- Kind == LiteralKind.String
- StringValue == "Seattle"
The compiler decides the corresponding column is a string column — so its runtime type is ValueString.
CreateStringLiteral("Seattle") runs:
- start with type = typeof(StringEnd)
- iterate characters from right to left:
  - 'e' → Char<…> type (4 hex digits that encode Unicode code point)
  - type = StringNode<Char<'e'>, StringEnd>
  - 'l' → Char<…>
  - type = StringNode<Char<'l'>, StringNode<Char<'e'>, StringEnd>>
  - repeat for each character: 't', 't', 'a', 'e', 'S'
- end result is something conceptually like:
```
 StringNode<Char<'S'>,
   StringNode<Char<'e'>,
     StringNode<Char<'a'>,
       StringNode<Char<'t'>,
         StringNode<Char<'t'>,
           StringNode<Char<'l'>,
             StringNode<Char<'e'>, StringEnd>>>>>>>>
```
Finally, StringLiteral<> wraps that node type:

   StringLiteral<
     StringNode<Char<'S'>,
       StringNode<Char<'e'>,
         ...
       >
     >
   >

This single closed generic type is the string literal 'Seattle'. When a filter needs the value, it calls TLiteral.Value, which reconstructs a ValueString("Seattle") through TString.Length and TString.Write.

3.2.2 Null string literals

null is special:

If you write WHERE Team != null, the parser emits LiteralKind.Null.
For a string column, CreateStringLiteral(null) returns typeof(StringLiteral<StringNull>).
StringNull.Length == -1, so StringLiteral<StringNull>.Value returns new ValueString(null).

This way, null and "" are clearly distinguishable at the type level and runtime.

3.3 Literal factory

All of these encodings are wired together by LiteralTypeFactory:

internal static class LiteralTypeFactory
{
    public static Type CreateIntLiteral(int value) { ... }
    public static Type CreateFloatLiteral(float value) { ... }
    public static Type CreateBoolLiteral(bool value) { ... }
    public static Type CreateStringLiteral(string? value) { ... }
}

The SQL compiler calls these based on:

the runtime column type (int, float, bool, ValueString)
the literal kind (Integer, Float, Boolean, String, Null)

The end result: every literal in the WHERE clause is a concrete ILiteral<T> type with its value embedded in the type arguments.

4. Building the pipeline type

By now we have:

a parsed query (SELECT + WHERE)
a schema mapping column names to IColumn<TRow, TValue> implementations
a way to map literals to ILiteral<T> types

The compiler’s job is to turn this into:

a closed pipeline type TPipeline implementing IQueryNode<TRow, TRuntimeResult, TRoot>
a runtime result type TRuntimeResult
a public result type TPublicResult

4.1 Handling `SELECT`

First, the SELECT part.

`SELECT *`

The simplest case: SELECT * FROM $.

Both runtime and public result types are TRow.
The pipeline tail is just a Stop<TRow, TRow> node.

Conceptually:

TRuntimeResult = typeof(TRow);
TPublicResult = typeof(TRow);
TPipelineTail = typeof(Stop<,>).MakeGenericType(TRuntimeResult, typeof(TRow));

`SELECT col` / `SELECT col1, col2, ...`

For projections:

SELECT col:
- resolve the column into ColumnMetadata
- decide its runtime value type:
- if ValueType != string, runtime type is the same
- if ValueType == string, runtime type is ValueString
- build a ColumnProjection<TRuntimeColumn, TRow, TRuntimeValue> node
SELECT col1, col2, ...:
- resolve each column
- build a ValueTupleProjection that constructs a ValueTuple<...> of runtime value types
- separately record the public ValueTuple<...> of declared CLR types

Finally, regardless of arity, a Select node is prepended before the Stop:

Select<TRow, TProjection, Stop<...>, TMiddle, TRuntimeResult, TRoot> → Stop<...>

This node calls the projection’s static Project and forwards the result to Stop.Process.

4.2 Handling `WHERE`

The WHERE clause is compiled recursively.

Boolean structure

Given a parsed WhereExpression tree:

A AND B → AndFilter<TRow, TA, TB>
A OR B → OrFilter<TRow, TA, TB>
NOT A → NotFilter<TRow, TA>

The compiler maps each node to a filter type by calling itself recursively:

Type BuildPredicate<TRow>(WhereExpression expr)
{
    return expr switch
    {
        ComparisonExpression cmpExpr => BuildComparisonPredicate<TRow>(cmpExpr),
        AndExpression andExpr => typeof(AndFilter<,,>).MakeGenericType(typeof(TRow), BuildPredicate<TRow>(andExpr.Left), BuildPredicate<TRow>(andExpr.Right)),
        OrExpression orExpr => typeof(OrFilter<,,>).MakeGenericType(typeof(TRow), BuildPredicate<TRow>(orExpr.Left), BuildPredicate<TRow>(orExpr.Right)),
        NotExpression notExpr => typeof(NotFilter<,>).MakeGenericType(typeof(TRow), BuildPredicate<TRow>(notExpr.Expression)),
        _ => throw …
    };
}

Leaf comparisons

Each comparison like:

City = 'Seattle'
Salary >= 180000
Team != null

becomes a concrete filter type:

Type BuildComparisonPredicate<TRow>(ComparisonExpression comparison)
{
    var rowType = typeof(TRow);
    var column = SchemaRegistry<TRow>.ResolveColumn(comparison.ColumnIdentifier);

    var runtimeColumnType      = column.GetRuntimeColumnType(rowType);
    var runtimeColumnValueType = column.GetRuntimeValueType();

    var literalType = CreateLiteralType(runtimeColumnValueType, comparison.Literal);

    var filterDefinition = comparison.Operator switch
    {
        ComparisonOperator.Equals        => typeof(EqualsFilter<,,,>),
        ComparisonOperator.GreaterThan   => typeof(GreaterThanFilter<,,,>),
        ComparisonOperator.LessThan      => typeof(LessThanFilter<,,,>),
        ComparisonOperator.GreaterOrEqual=> typeof(GreaterOrEqualFilter<,,,>),
        ComparisonOperator.LessOrEqual   => typeof(LessOrEqualFilter<,,,>),
        ComparisonOperator.NotEqual      => typeof(NotEqualFilter<,,,>),
        _ => throw …
    };

    return filterDefinition.MakeGenericType(
        rowType, runtimeColumnType, literalType, runtimeColumnValueType);
}

So, for example, City = 'Seattle' against a string column:

runtime column type is ValueStringColumn<PersonCityColumn, Person>
runtime value type is ValueString
literal type is StringLiteral<SomeStringNode<…>> (via CreateStringLiteral("Seattle"))

The final filter type is:

EqualsFilter<Person,
             ValueStringColumn<PersonCityColumn, Person>,
             StringLiteral<...>,
             ValueString>

Finally, a Where node is attached:

Where<TRow, TPredicate, TNext, TRuntimeResult, TRoot> → ...

4.3 Fusing `Where` and `Select`

The resulting pipeline is correct but not optimal: Where and Select are separate stages.

There’s a tiny optimizer that looks for patterns like:

Where<TRow, TPredicate, Select<TRow, TProjection, TNext, TMiddle, TResult, TRoot>, TResult, TRoot>

and fuses them into:

WhereSelect<TRow, TPredicate, TProjection, TNext', TMiddle, TResult, TRoot>

The fused node:

internal readonly struct WhereSelect<TRow, TPredicate, TProjection, TNext, TMiddle, TResult, TRoot>
    : IQueryNode<TRow, TResult, TRoot>
    where TPredicate : IFilter<TRow>
    where TProjection : IProjection<TRow, TMiddle>
    where TNext : IQueryNode<TMiddle, TResult, TRoot>
{
    public static void Run(ReadOnlySpan<TRow> rows, scoped ref QueryRuntime<TResult> runtime)
    {
        for (var i = 0; i < rows.Length; i++)
        {
            Process(in rows[i], ref runtime);
        }
    }

    public static void Process(in TRow row, scoped ref QueryRuntime<TResult> runtime)
    {
        if (TPredicate.Evaluate(in row))
        {
            var projected = TProjection.Project(in row);
            TNext.Process(in projected, ref runtime);
        }
    }
}

Common queries like:

SELECT Name FROM $ WHERE City = 'Seattle'

end up as:

WhereSelect<...> → Stop<...>

i.e. a single pass: filter and projection in the same tight loop. Moreover, our optimizer can also recognize more complex nested structures and fuse Where and Select together wherever possible to reduce intermediate steps and improve performance. This doesn’t require any sophisticated optimization algorithms — we just pull out the generic type arguments and plug them into the fused type, which makes the implementation very straightforward.

5. Result conversion

Once the static pipeline has processed the rows, we need to expose the results to the caller.

The generic entry point for a query is:

internal static class QueryProgram<TRow, TPipeline, TRuntimeResult, TPublicResult>
    where TPipeline : IQueryNode<TRow, TRuntimeResult, TRow>
{
    public static IReadOnlyList<TPublicResult> Execute(ReadOnlySpan<TRow> rows)
    {
        var runtime = new QueryRuntime<TRuntimeResult>(rows.Length);
        TPipeline.Run(rows, ref runtime);

        return ConvertResult(ref runtime);
    }

    private static IReadOnlyList<TPublicResult> ConvertResult(ref QueryRuntime<TRuntimeResult> runtime)
    {
        if (typeof(IReadOnlyList<TRuntimeResult>) == typeof(IReadOnlyList<TPublicResult>))
        {
            return (IReadOnlyList<TPublicResult>)(object)runtime.Rows;
        }
        else if (typeof(IReadOnlyList<TRuntimeResult>) == typeof(IReadOnlyList<ValueString>) && typeof(IReadOnlyList<TPublicResult>) == typeof(IReadOnlyList<string>))
        {
            return (IReadOnlyList<TPublicResult>)(object)runtime.AsStringRows();
        }
        else if (RuntimeFeature.IsDynamicCodeSupported && typeof(TRuntimeResult).IsGenericType && typeof(TPublicResult).IsGenericType)
        {
            return runtime.AsValueTupleRows<TPublicResult>();
        }

        throw new InvalidOperationException($"Cannot convert query result from '{typeof(TRuntimeResult)}' to '{typeof(TPublicResult)}'.");
    }
}

So there are three main cases:

Runtime and public types are identical

→ just return Rows.
Runtime uses ValueString, public expects string

→ use AsStringRows, which wraps the underlying ValueString[] and returns string? via implicit conversion.
Both are ValueTuple shapes

→ use AsValueTupleRows<TPublicResult>(), which delegates to ValueTupleConvertHelper.

5.3 `ValueTupleConvertHelper`: copying fields with dynamic IL

ValueTupleConvertHelper<TPublicResult, TRuntimeResult> is responsible for:

copying one ValueTuple into another with compatible shapes
handling string ↔ ValueString conversions on individual fields
recursing into nested ValueTuple<..., TRest> tails

It uses a DynamicMethod to generate a copy method at type‑initializer time:

internal static class ValueTupleConvertHelper<TPublicResult, TRuntimeResult>
{
    private delegate void CopyDelegate(ref TPublicResult dest, ref readonly TRuntimeResult source);

    private static readonly CopyDelegate _helper = default!;

    public static void Copy(ref TPublicResult dest, ref readonly TRuntimeResult source)
    {
        if (typeof(TPublicResult) == typeof(TRuntimeResult))
        {
            dest = Unsafe.As<TRuntimeResult, TPublicResult>(ref Unsafe.AsRef(in source));
        }
        else
        {
            _helper.Invoke(ref dest, in source);
        }
    }

    static ValueTupleConvertHelper()
    {
        // Create DynamicMethod and IL to copy fields, including string <-> ValueString
        // and nested Rest fields.
    }
}

The generated IL:

walks the fields Item1 … Item7 and Rest of ValueTuple
for each field:
- if field types are identical, just copy
- if one side is string and the other is ValueString, convert via wrapping/unwrapping
recurses through nested Rest until the end

This means the runtime can store a tuple of internal types like (ValueString, int, ValueString, …) while the public type can be (string, int, string, …) — and they are bridged cheaply.

Here we use DynamicMethod for dynamic IL generation, which may not be available in AOT or other restricted environments. TypedSql checks for dynamic code generation support at runtime and only enables this path when available; otherwise, it falls back to requiring that runtime and public result types match exactly.

6. Putting it together: compile and execute

From the user’s point of view, the entry point looks like this:

var compiled = QueryEngine.Compile<Person, string>(
    "SELECT Name FROM $ WHERE City != 'Seattle'");

Internally, Compile<TRow, TResult>:

Parses the SQL into a ParsedQuery.
Calls the SQL compiler to get:
- the pipeline type TPipeline
- TRuntimeResult
- TPublicResult
Asserts that TPublicResult matches the TResult you requested.
Constructs QueryProgram<TRow, TPipeline, TRuntimeResult, TPublicResult>.
Locates its static Execute(ReadOnlySpan<TRow>) method.
Converts it to a delegate and returns a CompiledQuery<TRow, TResult> wrapper.

CompiledQuery<TRow, TResult> then just holds:

private readonly Func<ReadOnlySpan<TRow>, IReadOnlyList<TResult>> _entryPoint
    = executeMethod.CreateDelegate<Func<ReadOnlySpan<TRow>, IReadOnlyList<TResult>>>();

and exposes:

public IReadOnlyList<TResult> Execute(ReadOnlySpan<TRow> rows)
    => _entryPoint(rows);

Thanks to the optimizations around escape analysis, devirtualization and inlining for delegates in .NET 10, this abstraction does not add measurable overhead.

From the JIT’s perspective, once Compile has run, every Execute is just:

a direct static call
into a generic method where all type arguments are closed
that calls a static pipeline of struct nodes, filters, and projections.

7. Usage, tests, and benchmarks

7.1 Usage pattern

The typical workflow with TypedSql is:

Define your row type:

   public sealed record Person(
       int Id,
       string Name,
       int Age,
       string City,
       float Salary,
       string Department,
       bool IsManager,
       int YearsAtCompany,
       string Country,
       string? Team,
       string Level);

Implement IColumn<Person, TValue> for each column you want to query on.
Register them in a schema for Person.
Compile and run queries, for example:

   // Compile once
   var wellPaidManagers = QueryEngine.Compile<Person, Person>(
       "SELECT * FROM $ " +
       "WHERE Department = 'Engineering' " +
       "AND IsManager = true " +
       "AND YearsAtCompany >= 5 " +
       "AND Salary > 170000 " +
       "AND Country = 'US'");

   // Execute over different data sets
   var result = wellPaidManagers.Execute(allPeople.AsSpan());

Or a projection query returning tuples:

var seniorTitles = QueryEngine.Compile<Person, (string Name, string City, string Level)>(
    "SELECT Name, City, Level FROM $ " +
    "WHERE Level = 'Senior' AND City = 'Seattle'");

foreach (var (name, city, level) in seniorTitles.Execute(allPeople.AsSpan()))
{
    Console.WriteLine($"{name} in {city} [{level}]");
}

All the heavy lifting — parsing, literal encoding, type‑level pipeline generation — happens once at compile time of the query. Every .Execute after that is just running a specialized static pipeline.

7.2 Benchmarks

TypedSql’s motivation was not “be clever with types for the sake of it”, but to see how close we can get to a handwritten loop while keeping a SQL‑like surface.

A simple benchmark compares three approaches over the same in‑memory dataset:

a TypedSql query
an equivalent LINQ query
a handwritten foreach

The workload:

filter rows where City == "Seattle"
return their Ids

TypedSql compiles to a pipeline like this (for a query that filters City == "Seattle" and projects Id):

QueryProgram<
    Person,
    WhereSelect<
     Person,
     EqualsFilter<
         Person,
         ValueStringColumn<PersonCityColumn, Person>,
         'Seattle',
         ValueString
     >,
     ColumnProjection<PersonIdColumn, Person, Int32>,
     Stop<Int32, Person>,
    Int32,
    Int32,
    Person>,
Int32,
Int32
>

RyuJIT turns that into machine code roughly like this (trimmed for brevity):

G_M000_IG01:                ; prologue
    push     r15
    push     r14
    push     rdi
    push     rsi
    push     rbp
    push     rbx
    sub      rsp, 40
    mov      rbx, rcx

G_M000_IG02:                ; allocate result array
    mov      esi, dword ptr [rbx+0x08]
    mov      edx, esi
    mov      rcx, 0x7FFE71F29558
    call     CORINFO_HELP_NEWARR_1_VC
    mov      rdi, rax
    xor      ebp, ebp
    mov      rbx, bword ptr [rbx]
    test     esi, esi
    jle      SHORT G_M000_IG06

G_M000_IG03:                ; init loop index
    xor      r14d, r14d

G_M000_IG04:                ; loop body
    lea      r15, bword ptr [rbx+r14]
    mov      rcx, gword ptr [r15+0x08]
    mov      rdx, 0x16EB0400D30
    mov      rdx, gword ptr [rdx]
    mov      rdx, gword ptr [rdx+0x08]
    cmp      rcx, rdx
    je       G_M000_IG12
    test     rcx, rcx
    je       SHORT G_M000_IG05
    test     rdx, rdx
    je       SHORT G_M000_IG05
    mov      r8d, dword ptr [rcx+0x08]
    cmp      r8d, dword ptr [rdx+0x08]
    je       SHORT G_M000_IG08

G_M000_IG05:                ; advance index
    add      r14, 72
    dec      esi
    jne      SHORT G_M000_IG04

G_M000_IG06:                ; wrap result
    mov      rcx, 0x7FFE72227600
    call     CORINFO_HELP_NEWSFAST
    mov      rbx, rax
    lea      rcx, bword ptr [rbx+0x08]
    mov      rdx, rdi
    call     CORINFO_HELP_ASSIGN_REF
    mov      dword ptr [rbx+0x10], ebp
    mov      rax, rbx

G_M000_IG07:                ; epilogue
    add      rsp, 40
    pop      rbx
    pop      rbp
    pop      rsi
    pop      rdi
    pop      r14
    pop      r15
    ret

G_M000_IG08:                ; string length compare
    lea      rax, bword ptr [rcx+0x0C]
    add      rdx, 12
    mov      ecx, dword ptr [rcx+0x08]
    add      ecx, ecx
    mov      r8d, ecx
    cmp      r8, 10
    je       SHORT G_M000_IG10

G_M000_IG09:                ; slow path compare
    mov      rcx, rax
    call     [System.SpanHelpers:SequenceEqual(byref,byref,nuint):bool]
    jmp      SHORT G_M000_IG11

G_M000_IG10:                ; fast path compare for length 10
    mov      rcx, qword ptr [rax]
    mov      rax, qword ptr [rax+0x02]
    mov      r8, qword ptr [rdx]
    xor      rcx, r8
    xor      rax, qword ptr [rdx+0x02]
    or       rcx, rax
    sete     al
    movzx    rax, al

G_M000_IG11:                ; branch on comparison result
    test     eax, eax
    je       SHORT G_M000_IG05

G_M000_IG12:                ; write matching Id
    mov      ecx, dword ptr [r15+0x30]
    lea      rax, bword ptr [rdi+0x10]
    lea      edx, [rbp+0x01]
    mov      r15d, edx
    movsxd   rdx, ebp
    mov      dword ptr [rax+4*rdx], ecx
    mov      ebp, r15d
    jmp      G_M000_IG05

There are a few interesting details here:

In G_M000_IG08, the compare cmp r8, 10 bakes the literal length of 'Seattle' into the code, and G_M000_IG10 is a dedicated fast path for strings of that length.
In G_M000_IG05, the add r14, 72 uses sizeof(Person) as a constant step, and the loop counter is turned into a simple decrement (dec esi), which minimizes branches.

Semantically, the loop is equivalent to:

int length = elements.Length;
Span<int> values = new int[length];
int count = 0;

for (int i = length - 1; i >= 0; i--)
{
    var elem = elements[i];
    var city = elem.City;
    if (city == null)
     continue;

    if (city.Length == 10 && city == "Seattle")
    {
     values[length - 1 - count] = elem.Id;
     count++;
    }
}

return values[..count];

In other words, the abstractions in TypedSql compile down to something extremely close to a hand‑written loop, with constants for both the string literal and row size baked into the machine code.

The benchmark numbers back this up:

Method	Mean	Error	StdDev	Gen0	Code Size	Allocated
TypedSql	10.953 ns	0.0250 ns	0.0195 ns	0.0051	111 B	80 B
Linq	27.030 ns	0.1277 ns	0.1067 ns	0.0148	3,943 B	232 B
Foreach	9.429 ns	0.0417 ns	0.0326 ns	0.0046	407 B	72 B

This matches the internal structure we designed:

the query pipeline is expressed at the type level, and its shape is fixed at compile time
columns, projections, and filters are all value types with static methods
strings go through the ValueString hot path
literals are embedded into type parameters via ILiteral<T>
all of this lets the JIT specialize, unroll, and inline aggressively, producing machine code that is almost indistinguishable from a handwritten loop

8. Closing thoughts

TypedSql is a small in‑memory query engine experiment. It focuses on a very specific question: how much query logic can we push into the C# type system, and how fast can .NET run such type‑driven code?

In TypedSql, we:

represent columns, projections, and filters as structs with static methods, constrained by interfaces with static abstract members
compose them into nested generic pipeline nodes (Where, Select, WhereSelect, Stop)
encode numeric and string literals as types (ILiteral<T>) so that literal values live in type parameters

The end result is a small, SQL‑like in‑memory query engine. To the JIT, it is just a collection of highly optimizable, type‑specialized loops; to you, it still looks and feels like writing SQL.

So the answer is yes: the .NET type system is powerful enough to express Turing‑complete logic, and with help from the JIT, it can generate very efficient code.

Looking ahead, the same ideas could be applied to query engines, DSL compilers, and even language runtimes: use the type system to encode structure, let the JIT do the heavy lifting, and, when needed, emit the constructed types as source and compile them with NativeAOT to get native binaries. You get both JIT and AOT from the same codebase, and—unlike C++ templates or constexpr—you can still feed it dynamic input at runtime.

The project is open source on GitHub: TypedSql, where you can explore the full implementation, run the benchmarks, and try it out with your own data!

Build a high-performance Brainf**k JIT and AOT compiler on top of C# type system

Steve — Sat, 15 Feb 2025 17:59:14 +0000

What is Brainfuck?

Brainfuck is a very simple, Turing-complete programming language devised by Urban Müller in 1993.

Its simplicity is remarkable: a program can be written using just eight symbols.

If we were to express it in a C-like way, it would look like this:

Symbol	Meaning
`>`	`++ptr`
`<`	`--ptr`
`+`	`++*ptr`
`-`	`--*ptr`
`.`	`putchar(*ptr)`
`,`	`*ptr = getchar()`
`[`	`while (*ptr) {`
`]`	`}`

All you need is a byte array (memory) initialized to zero, a pointer to that array, and two byte streams for input and output. That’s enough to run a Brainfuck program.

Here’s an example program that outputs “Hello World!”:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]
>++.>+.+++++++..+++.>++.<<+++++++++++++++.
>.+++.------.--------.>+.>.

Dig into the C# Type System

I’ll give a quick, high-level look at the main parts of the C# type system that I used to build this compiler.

Generics

The C# type system is built on .NET, and .NET actually instantiates generic types. In other words, generic parameters aren’t just erased; the runtime specializes code for each parameter.

For example:

class Foo<T>
{
    public void Print() => Console.WriteLine(default(T)?.ToString() ?? "null");
}

new Foo<int>().Print() prints 0,
new Foo<DateTime>().Print() prints 0001-01-01T00:00:00,
new Foo<string>().Print() prints null.

Moreover, since .NET’s generics specialize code at runtime for each type, you can rest easy with code like this:

class Calculator<T> where T : IAdditionOperators<T, T, T>
{
    public T Add(T left, T right)
    {
        return left + right;
    }
}

Looking at godbolt, you can see that machine code optimized for each type is generated:

Calculator`1[int]:Add(int,int):int:this (FullOpts):
       lea      eax, [rsi+rdx]
       ret      

Calculator`1[long]:Add(long,long):long:this (FullOpts):
       lea      rax, [rsi+rdx]
       ret      

Calculator`1[ubyte]:Add(ubyte,ubyte):ubyte:this (FullOpts):
       add      edx, esi
       movzx    rax, dl
       ret      

Calculator`1[float]:Add(float,float):float:this (FullOpts):
       vaddss   xmm0, xmm0, xmm1
       ret      

Calculator`1[double]:Add(double,double):double:this (FullOpts):
       vaddsd   xmm0, xmm0, xmm1
       ret

That way, if you give it different types, code specialized for each one is generated automatically.

Static Abstract Members in Interfaces

You might wonder how Calculator<T> can simply add left and right within the method. That’s because .NET supports static abstract members in interfaces. For instance, IAdditionOperators is defined roughly like this:

interface IAdditionOperators<TSelf, TOther, TResult>
{
    abstract static TResult operator+(TSelf self, TOther other);
}

And by specifying where T : IAdditionOperators<T, T, T>, the generic code can directly call operator+ on T.

How’s Performance?

With the above knowledge, you might want to see how well the .NET compiler can optimize when using the type system. Let’s take int (32 bits) as an example—something we’ll need for the Brainfuck compiler. If you represent a 32-bit integer as eight hexadecimal digits, each digit can be a type, and you can combine those eight digits into one type representing the entire number.

First, define an interface for a hexadecimal digit:

interface IHex
{
    abstract static int Value { get; }
}

For example, the hex digits 0, 6, and C can be represented as:

struct Hex0 : IHex
{
    public static int Value => 0;
}

struct Hex6 : IHex
{
    public static int Value => 6;
}

struct HexC : IHex
{
    public static int Value => 12;
}

To distinguish between a “digit” and a full “number,” let’s define another generic interface INum<T> and use an Int struct to implement it. (The idea is that in the future, it might be extended to support floating-point, etc.)

interface INum<T>
{
    abstract static T Value { get; }
}

struct Int<H7, H6, H5, H4, H3, H2, H1, H0> : INum<int>
    where H7 : IHex
    where H6 : IHex
    where H5 : IHex
    where H4 : IHex
    where H3 : IHex
    where H2 : IHex
    where H1 : IHex
    where H0 : IHex
{
    public static int Value
    {
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        get => H7.Value << 28 
               | H6.Value << 24 
               | H5.Value << 20 
               | H4.Value << 16 
               | H3.Value << 12 
               | H2.Value << 8  
               | H1.Value << 4  
               | H0.Value;
    }
}

So if you want to represent the hexadecimal value 0x1234abcd, you would write:

Int<Hex1, Hex2, Hex3, Hex4, HexA, HexB, HexC, HexD>

Here, we put [MethodImpl(MethodImplOptions.AggressiveInlining)] on the method to strongly suggest inlining to the compiler.

Taking a look at the godbolt compile result, you can see it gets directly optimized into 0x1234ABCD:

Int`8[Hex1,Hex2,Hex3,Hex4,HexA,HexB,HexC,HexD]:get_Value():int (FullOpts):
       push     rbp
       mov      rbp, rsp
       mov      eax, 0x1234ABCD
       pop      rbp
       ret

This is a great example of “zero-overhead abstraction”!

Now that we’re confident about performance, let’s finally build our Brainfuck compiler.

Building the Brainfuck Compiler

Compiling Brainfuck typically involves two main steps:

Parsing the Brainfuck source code.
Generating the compilation result.

Parsing is straightforward: scan the code from left to right and handle each command. We won’t go into detail on that here. Instead, we’ll focus on how we generate the compiled result.

In this project, we represent the program itself as a type. In other words, the compiled result is literally a type.

Basic Operations

Brainfuck needs four fundamental operations:

Pointer movement
Memory manipulation
Input
Output

To abstract these, we define an interface for operations:

interface IOp
{
    abstract static int Run(int address, Span<byte> memory, Stream input, Stream output);
}

Then we make each operation into a type.

Pointer Movement

Pointer movement can be handled by a type parameter Offset (how far to move) and Next (the next operation):

struct AddPointer<Offset, Next> : IOp
    where Offset : INum<int>
    where Next : IOp
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int Run(int address, Span<byte> memory, Stream input, Stream output)
    {
        return Next.Run(address + Offset.Value, memory, input, output);
    }
}

Memory Manipulation

Next, manipulating data at the pointer:

struct AddData<Data, Next> : IOp
    where Data : INum<int>
    where Next : IOp
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int Run(int address, Span<byte> memory, Stream input, Stream output)
    {
        memory.UnsafeAt(address) += (byte)Data.Value;
        return Next.Run(address, memory, input, output);
    }
}

Brainfuck typically omits memory boundary checks, so we do a little trick with an UnsafeAt extension method to avoid overhead:

internal static ref T UnsafeAt<T>(this Span<T> span, int address)
{
    return ref Unsafe.Add(ref MemoryMarshal.GetReference(span), address);
}

Input and Output

Input and output are pretty straightforward:

struct OutputData<Next> : IOp
    where Next : IOp
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int Run(int address, Span<byte> memory, Stream input, Stream output)
    {
        output.WriteByte(memory.UnsafeAt(address));
        return Next.Run(address, memory, input, output);
    }
}

struct InputData<Next> : IOp
    where Next : IOp
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int Run(int address, Span<byte> memory, Stream input, Stream output)
    {
        var data = input.ReadByte();
        if (data == -1)
        {
            return address;
        }
        memory.UnsafeAt(address) = (byte)data;
        return Next.Run(address, memory, input, output);
    }
}

Control Flow

Besides the basic operations, Brainfuck also needs control flow. In the end, a program needs to stop, so let’s create an operation that does nothing (Stop):

struct Stop : IOp
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int Run(int address, Span<byte> memory, Stream input, Stream output)
    {
        return address;
    }
}

Brainfuck loops behave like while (*ptr != 0) { ... }. So we can write:

struct Loop<Body, Next> : IOp
    where Body : IOp
    where Next : IOp
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static int Run(int address, Span<byte> memory, Stream input, Stream output)
    {
        while (memory.UnsafeAt(address) != 0)
        {
            address = Body.Run(address, memory, input, output);
        }
        return Next.Run(address, memory, input, output);
    }
}

Let’s Make an Actual Program

With all these building blocks, we can represent a Brainfuck program as a C# type.

Hello World!

The well-known (to some) “Hello World!” Brainfuck code is:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]
>++.>+.+++++++..+++.>++.<<+++++++++++++++.
>.+++.------.--------.>+.>.

But this code can be hard to read at first glance, so I rewrote it in a more “intuitive” way:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
++++++++++++++++++++++++++++++++>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
+++++++++++++++++++++++++++++++++
<<<<<<<<<<<
.>.>.>.>.>.>.>.>.>.>.>.

This program places each character of “Hello World!” into successive cells moving from left to right, then moves the pointer back to the start and prints them all.

Still, “Hello World!” is pretty long, so here’s a simpler example that just prints 123:

+++++++++++++++++++++++++++++++++++++++++++++++++
>
++++++++++++++++++++++++++++++++++++++++++++++++++
>
+++++++++++++++++++++++++++++++++++++++++++++++++++
<<
.>.>.

This program sets the ASCII codes for 1, 2, and 3 in consecutive cells, moves the pointer back to the first cell, and then outputs them in order.

In terms of types, it looks like this:

AddData<49, AddPointer<1, AddData<50, AddPointer<1, AddData<51, // each sets the bytes for '1', '2', '3'
AddPointer<-2, // move pointer back to the start
OutputData<AddPointer<1, OutputData<AddPointer<1, OutputData< // output
Stop>>>>>>>>>>>

(For simplicity, I wrote 49, 50, and 51 directly. In reality, you’d use something like Int<Hex0, Hex0, Hex0, Hex0, Hex0, Hex0, Hex3, Hex1> to represent 49.)

How to Run It

Running it is super easy! Just write:

AddData<49, AddPointer<1, AddData<50, AddPointer<1, AddData<51, AddPointer<-2, OutputData<AddPointer<1, OutputData<AddPointer<1, OutputData<Stop>>>>>>>>>>>
    .Run(0, stackalloc byte[8], Console.OpenStandardInput(), Console.OpenStandardOutput());

And if you use a C# type alias, you can avoid typing such a huge generic each time:

using Print123 = AddData<49, AddPointer<1, AddData<50, AddPointer<1, AddData<51, AddPointer<-2, OutputData<AddPointer<1, OutputData<AddPointer<1, OutputData<Stop>>>>>>>>>>>;

Print123.Run(0, stackalloc byte[8], Console.OpenStandardInput(), Console.OpenStandardOutput());

On godbolt, the generated machine code looks like this:

push     rbp
push     r15
push     r14
push     r13
push     rbx
lea      rbp, [rsp+0x20]
mov      rbx, rsi
mov      r15, r8
movsxd   rsi, edi
add      rsi, rbx
add      byte  ptr [rsi], 49 ; '1'
inc      edi
movsxd   rsi, edi
add      rsi, rbx
add      byte  ptr [rsi], 50 ; '2'
inc      edi
movsxd   rsi, edi
add      rsi, rbx
add      byte  ptr [rsi], 51 ; '3'
lea      r14d, [rdi-0x02]
movsxd   rsi, r14d
movzx    rsi, byte  ptr [rbx+r14d]
mov      rdi, r15
mov      rax, qword ptr [r15]
mov      r13, qword ptr [rax+0x68]
call     [r13]System.IO.Stream:WriteByte(ubyte):this
inc      r14d
movsxd   rsi, r14d
movzx    rsi, byte  ptr [rbx+r14d]
mov      rdi, r15
call     [r13]System.IO.Stream:WriteByte(ubyte):this
inc      r14d
movsxd   rsi, r14d
movzx    rsi, byte  ptr [rbx+r14d]
mov      rdi, r15
call     [r13]System.IO.Stream:WriteByte(ubyte):this
mov      eax, r14d
pop      rbx
pop      r13
pop      r14
pop      r15
pop      rbp
ret

If you wrote this in C, it would be something like:

*(ptr++) = '1';
*(ptr++) = '2';
*ptr = '3';
ptr -= 2;
WriteByte(*(ptr++));
WriteByte(*(ptr++));
WriteByte(*ptr);

In other words, C#’s type-based abstractions are optimized away at runtime, leaving no extra overhead at all.

By the way, remember the “less intuitive” version of Hello World! code above?

If you compile it, you’ll get a type name that is extraordinarily long:

AddData<8, Loop<
    AddPointer<1, AddData<4, Loop<
        AddPointer<1, AddData<2, AddPointer<1, AddData<3, AddPointer<1, AddData<3, AddPointer<1, AddData<1, AddPointer<-4, AddData<-1, Stop>>>>>>>>>>,
        AddPointer<1, AddData<1, AddPointer<1, AddData<1, AddPointer<1, AddData<-1, AddPointer<2, AddData<1,
            Loop<AddPointer<-1, Stop>,
            AddPointer<-1, AddData<-1, Stop>>
        >>>>>>>>>
    >>>,
    AddPointer<2, OutputData<AddPointer<1, AddData<-3, OutputData<AddData<7, OutputData<OutputData<AddData<3, OutputData<AddPointer<2, OutputData<AddPointer<-1, AddData<-1, OutputData<AddPointer<-1, OutputData<AddData<3, OutputData<AddData<-6, OutputData<AddData<-8, OutputData<AddPointer<2, AddData<1, OutputData<AddPointer<1, AddData<2, OutputData<Stop>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

JIT Compilation

To run Brainfuck code just-in-time, you can generate the type at runtime and call its Run method via reflection. For example, creating a type that represents a number:

var type = GetNum(42);

static Type GetHex(int hex)
{
    return hex switch
    {
        0 => typeof(Hex0),
        1 => typeof(Hex1),
        2 => typeof(Hex2),
        3 => typeof(Hex3),
        4 => typeof(Hex4),
        5 => typeof(Hex5),
        6 => typeof(Hex6),
        7 => typeof(Hex7),
        8 => typeof(Hex8),
        9 => typeof(Hex9),
        10 => typeof(HexA),
        11 => typeof(HexB),
        12 => typeof(HexC),
        13 => typeof(HexD),
        14 => typeof(HexE),
        15 => typeof(HexF),
        _ => throw new ArgumentOutOfRangeException(nameof(hex)),
    };
}

static Type GetNum(int num)
{
    var hex0 = num & 0xF;
    var hex1 = (num >> 4) & 0xF;
    var hex2 = (num >> 8) & 0xF;
    var hex3 = (num >> 12) & 0xF;
    var hex4 = (num >> 16) & 0xF;
    var hex5 = (num >> 20) & 0xF;
    var hex6 = (num >> 24) & 0xF;
    var hex7 = (num >> 28) & 0xF;
    return typeof(Int<,,,,,,,>)
        .MakeGenericType(
            GetHex(hex7), GetHex(hex6), GetHex(hex5), GetHex(hex4),
            GetHex(hex3), GetHex(hex2), GetHex(hex1), GetHex(hex0)
        );
}

You’d do something similar for control flow, then call Run via reflection:

var run = (EntryPoint)Delegate.CreateDelegate(typeof(EntryPoint), type.GetMethod("Run")!);
run(0, memory, input, output);

delegate int EntryPoint(int address, Span<byte> memory, Stream input, Stream output);

AOT Compilation

If you prefer an AOT-compiled executable, you can just make the Brainfuck program type the entry point:

using HelloWorld = AddData<8, Loop<
    AddPointer<1, AddData<4, Loop<
        AddPointer<1, AddData<2, AddPointer<1, AddData<3, AddPointer<1, AddData<3, AddPointer<1, AddData<1, AddPointer<-4, AddData<-1, Stop>>>>>>>>>>,
        AddPointer<1, AddData<1, AddPointer<1, AddData<1, AddPointer<1, AddData<-1, AddPointer<2, AddData<1,
            Loop<AddPointer<-1, Stop>,
            AddPointer<-1, AddData<-1, Stop>>
        >>>>>>>>>
    >>>,
    AddPointer<2, OutputData<AddPointer<1, AddData<-3, OutputData<AddData<7, OutputData<OutputData<AddData<3, OutputData<AddPointer<2, OutputData<AddPointer<-1, AddData<-1, OutputData<AddPointer<-1, OutputData<AddData<3, OutputData<AddData<-6, OutputData<AddData<-8, OutputData<AddPointer<2, AddData<1, OutputData<AddPointer<1, AddData<2, OutputData<Stop>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>;

static void Main()
{
    HelloWorld.Run(0, stackalloc byte[16], Console.OpenStandardInput(), Console.OpenStandardOutput());
}

Then compile with:

dotnet publish -c Release -r linux-x64 /p:PublishAot=true /p:IlcInstructionSet=native /p:OptimizationPreference=Speed

(IlcInstructionSet=native is like -march=native in C++, and OptimizationPreference=Speed is akin to -O2.)

When you run the resulting executable, it prints “Hello World!” directly.

Benchmarks

I tested performance with a Brainfuck Mandelbrot program (source on Pastebin) that draws a Mandelbrot fractal, producing something like this:

And, when converted into a type representation (with all whitespace removed), the type name is a whopping 165,425 characters long!

I ran the resulting program in five ways:

C Interpreter A C-language Brainfuck interpreter (github link).
GCC Used a Brainfuck-to-C compiler (bf2c), then compiled with gcc -O3 -march=native.
Clang Similarly compiled with clang -O3 -march=native.
.NET JIT Generated the type at runtime, then ran it (warmed up first).
.NET AOT Used .NET NativeAOT to produce a standalone executable.

Environment:

OS: Debian GNU/Linux 12 (bookworm)
CPU: 13th Gen Intel® Core™ i7-13700K
RAM: CORSAIR DDR5-6800MHz 32G×2

I ran each method 10 times and took the fastest result. All output was redirected to /dev/null to avoid slowdowns from console I/O. The results:

Method	Time (ms)	Rank	Ratio
C Interpreter	4874.6587	5	5.59
GCC	901.0225	3	1.03
Clang	881.7177	2	1.01
.NET JIT	925.1596	4	1.06
.NET AOT	872.2287	1	1.00

Surprisingly, .NET AOT beat out C to claim first place. You could say this is all thanks to the zero-overhead abstractions the C# type system provides.

Conclusion

By leveraging the C# type system, building a Brainfuck compiler becomes more like a fun experiment rather than a daunting project. This project also proved that .NET has a flexible type system, with an advanced optimization compiler that can optimize away those abstractions to achieve high performance.

Project

The project is open sourced under MIT license: https://github.com/hez2010/Brainfly

Forem: Steve

Satori GC: High Throughput, Low Latency, and a Small Memory Footprint

Introduction

What a GC Actually Does

Generations

Write Barriers and Card Tables

The Impossible Triangle

What Satori Is Trying to Do

Page, Region, and Generations

Turning Gen 0 into a Local Problem

Escape Tracking

Thread-Local Collection

1. Decide Whether Collection Is Worth It

2. Mark from a Much Smaller Root Set

3. Plan Compaction

4. Update References and Compact Locally

A Simple Example

Global GC

Global GC Phases

Optional Relocation

Letting Application Threads Help Advance Collection

Low Memory Usage

1. Let Short-Lived Garbage Die Young

2. Explicitly Return Free Memory to the OS

3. Keep Metadata Overhead Under Control

Solving the Triangle: High Throughput, Low Latency, and Low Memory Usage

Why It Can Deliver Low Latency

Why It Can Deliver High Throughput

Why It Can Also Deliver Low Memory Usage

How It Compares with Other GCs

Workstation GC and Server GC

DATAS

G1

ZGC and Shenandoah

Conclusion

TypedSql: Turning the C# Type System into a High-Performance SQL Query Engine

0. Introduction

1. Design: queries as nested generic types

1.1 Execution plan in the type system

1.2 Columns and projections as value types

1.3 Filters as static structs

1.4 Special handling for strings: ValueString

2. Parsing a small SQL dialect

3. Literals as types — including string literals

3.1 Hex digits and numeric literals

3.2 String literals: type‑level linked lists

3.2.1 How a string becomes a type

3.2.2 Null string literals

3.3 Literal factory

4. Building the pipeline type

4.1 Handling SELECT

SELECT *

SELECT col / SELECT col1, col2, ...

4.2 Handling WHERE

Boolean structure

Leaf comparisons

4.3 Fusing Where and Select

5. Result conversion

5.3 ValueTupleConvertHelper: copying fields with dynamic IL

6. Putting it together: compile and execute

7. Usage, tests, and benchmarks

7.1 Usage pattern

7.2 Benchmarks

8. Closing thoughts

Build a high-performance Brainf**k JIT and AOT compiler on top of C# type system

What is Brainfuck?

Dig into the C# Type System

Generics

Static Abstract Members in Interfaces

How’s Performance?

Building the Brainfuck Compiler

Basic Operations

Pointer Movement

Memory Manipulation

Input and Output

Control Flow

Let’s Make an Actual Program

Hello World!

How to Run It

JIT Compilation

1.4 Special handling for strings: `ValueString`

4.1 Handling `SELECT`

`SELECT *`

`SELECT col` / `SELECT col1, col2, ...`

4.2 Handling `WHERE`

4.3 Fusing `Where` and `Select`

5.3 `ValueTupleConvertHelper`: copying fields with dynamic IL