Forem: sentomk

The 128-arm pattern dispatch problem and how we got from 11ns to 1.1ns

sentomk — Sun, 03 May 2026 12:06:18 +0000

The problem

Pattern matching on a large set of literal values looks clean in code but hits a wall at runtime. Every on() call constructs case objects for every arm.

With 128 arms, that is 128 object constructions per match call. At 11ns per call, this is fine for one-off use. Inside a hot loop, it is a disaster.

// Clean syntax, 128 case objects constructed per call
return match(x) | on(
  lit(0) >> handle_0,
  lit(1) >> handle_1,
  // ... 126 more arms
  _ >> default_handler
);

The cases are compile-time constants. The values do not change. But the library has to construct them every time because the on() call receives them as function arguments, and C++ evaluates arguments at the call site before any optimization pass can intervene.

This is not a bug in the library design. It is a structural cost of the pipeline syntax match(x) | on(...). The syntax gives you readable, composable matching. The cost is that the case list is a runtime object.

Or it was, until we found a way to make it not.

First attempt: static caching with `is_constant_evaluated()`

The idea was simple. If the match expression appears in a constexpr context, the compiler already knows the subject value and all the case values. We can unfold the entire match at compile time and bypass the runtime machinery entirely.

C++20 gave us std::is_constant_evaluated(). When this returns true, the compiler is evaluating this code in a constexpr context. We can take the static path:

template <typename Plan, typename Subject, typename CasesTuple>
constexpr auto dispatch(Subject& subject, CasesTuple&& cases) {
  if (std::is_constant_evaluated()) {
    // Compile-time path: unfold cases statically
    return static_dispatch<Plan>(subject, std::forward<CasesTuple>(cases));
  }
  // Runtime path: use the normal evaluation engine
  return runtime_dispatch<Plan>(subject, std::forward<CasesTuple>(cases));
}

Nice in theory. In practice, this only helps when the entire call site is constexpr. For runtime matches with compile-time-known case values, the cases are still constructed. The constexpr branch does not fire.

We needed something more aggressive: detect at compile time that every case in the list is a static literal, then build a dense dispatch table that the runtime evaluator can use as an O(1) lookup.

The trap: `[[no_unique_address]]` and `std::is_empty`

Static literal patterns look like empty types:

template <auto V, typename Cmp = std::equal_to<>>
struct static_literal_pattern {
  static constexpr auto value = V;
  [[no_unique_address]] Cmp cmp{};
};

std::equal_to<> is an empty type. [[no_unique_address]] should allow the compiler to optimize cmp to zero size, making the whole pattern trivially small.

We used std::is_empty as the gate for static caching eligibility:

// Naive check: if the pattern is empty, we can cache it
if constexpr (std::is_empty_v<pattern_t>) {
  // ... static cache path
}

This broke on GCC. The reason: [[no_unique_address]] is a permission, not a requirement. GCC does not apply it to non-empty base classes, even when the member is not a base class. The Cmp member, despite being an empty type, prevents the pattern from satisfying std::is_empty.

The static cache path was silently skipped. The dense dispatch table was never built. The 128-case match stayed at 11ns.

The fix: `sizeof <= 1`

The insight was that we do not actually need the type to be empty. We need it to be small enough that caching it is worthwhile. One byte is the smallest addressable unit. If a type is one byte, it can be treated as a tag with no runtime state.

// Fixed: check if the pattern is trivial to cache
template <typename T>
constexpr bool is_cacheable_pattern_v = sizeof(T) <= 1;

This works because static_literal_pattern has one static data member (value) and one potentially-zero-size member (cmp). On GCC, with [[no_unique_address]] not applied, the pattern might be 1 byte. On Clang, with the attribute applied, it might be 0 bytes (empty base optimization). Either way, sizeof <= 1 is true. The check is portable across GCC, Clang, and MSVC.

With this fix, the dispatch planner correctly identifies that all 128 cases are static literals. It builds a compile-time index table mapping subject values to case indices. The runtime evaluator becomes:

// Runtime: O(1) lookup with bounds check
if (subject >= min_value && subject <= max_value) {
  auto idx = case_index_table[subject - min_value];
  if (idx != k_invalid_case_index) {
    return invoke_handler(std::get<idx>(cases), subject);
  }
}
return otherwise_handler(subject);

The numbers

Benchmarked on an Intel i7-13700K, GCC 13.2, -O3 -march=native. Subject type: int, 128 literal arms, uniformly random input.

Approach	Latency	vs. switch
Original `on()` (constructs all cases)	10.79 ns	9.9x slower
`PTN_ON` macro (manual static, best practice)	1.16 ns	1.06x slower
Auto-cache (this fix)	1.13 ns	1.04x slower
Hand-written `switch` (theoretical lower bound)	1.09 ns	baseline

The auto-cache approach matches the previous best practice (the PTN_ON macro) and comes within 0.04ns of a hand-written switch statement. That 0.04ns gap comes from a branch predictor mispredict on the bounds check, which is not under library control.

For context: the original implementation was 9.9x slower than a hand-written switch. The fix brings it to 1.04x. A 10x improvement from changing one condition in the type traits.

What this says about library design

The interesting part is not the optimization itself. It is that the entire improvement came from a type trait that was answering the wrong question.

std::is_empty asks "does this type have zero size?" That is a property of the type in the abstract C++ machine. But the actual question we needed to answer was "can this pattern be cached without measurable overhead?" That is an engineering question, not a type theory one.

sizeof <= 1 answers the engineering question. It says: this type fits in one byte, which is the smallest unit the hardware can address. Whether the compiler achieves this through [[no_unique_address]], empty base optimization, or something else — we do not care. The result is portable and measurable.

This is a pattern I have seen across performance work: the clean theoretical property is not the one that matters. The dirty empirical threshold is.

Try it

The implementation is open source at github.com/sentomk/patternia. The dispatch planner lives in include/ptn/core/common/optimize.hpp. The static literal cache logic is in include/ptn/core/common/eval.hpp.

Header-only, C++17, no dependencies beyond the standard library.

Declarative JSON Dispatch in Modern C++

sentomk — Fri, 19 Dec 2025 19:34:50 +0000

Working with JSON in C++ is no longer a matter of parsing bytes. Mature libraries such as nlohmann/json already provide a robust, dynamic representation of JSON values. The real challenge emerges one layer above parsing: how to structure the control flow that interprets those values.

For small examples, a linear chain of if / else if checks is often sufficient. As soon as the logic becomes recursive or semantically nuanced—distinguishing empty arrays from non-empty ones, or recognizing objects with specific structural properties—the code begins to accumulate branching noise. Classification, branching, and behavior become tightly coupled, and the resulting control flow is difficult to reason about locally.

This article examines that problem from a different angle. Rather than asking how to optimize conditional logic, it asks whether the dispatch itself can be described declaratively, while still operating on an existing, dynamic JSON model.

The complete implementation discussed here is available at

https://github.com/sentomk/patternia/tree/main/samples/json_dispatch.

Only the essential fragments are shown below.

JSON as a semantic sum type

Although nlohmann::json is dynamically typed, its runtime behavior is effectively that of a sum type. A value is exactly one of several mutually exclusive alternatives: null, boolean, number, string, array, or object. Many real-world JSON consumers already reason about values in this way, even if the code does not make that structure explicit.

Once this perspective is adopted, the desired control flow becomes clearer. Each branch of interpretation should be defined by what kind of value it matches, possibly refined by additional semantic constraints, and finally associated with a concrete action. The difficulty lies not in expressing any individual check, but in expressing the structure of the dispatch itself.

Traditional approaches each fall short in different ways. Conditional chains scale poorly as cases accumulate. Visitor-style designs introduce indirection and boilerplate without addressing the semantic coupling between matching and behavior. Variant-based dispatch requires translating JSON into a closed algebraic data type, which is often impractical or undesirable.

What is missing is a way to describe dispatch logic directly, as a composition of semantic cases, without replacing the underlying data model.

A declarative match pipeline

The approach explored here expresses JSON interpretation as a single, explicit match pipeline. Each case states what it matches and what it does, without embedding that logic in control-flow scaffolding.

void parse_json(const json& j, int depth = 0) {
  match(j)
    .when(bind()[is_type(json::value_t::null)]    >> print_null(depth))
    .when(bind()[is_type(json::value_t::boolean)] >> print_bool(depth))
    .when(bind()[is_int]                           >> print_int(depth))
    .when(bind()[is_uint]                          >> print_uint(depth))
    .when(bind()[is_float]                         >> print_float(depth))
    .when(bind()[is_type(json::value_t::string)]  >> print_string(depth))
    .when(bind()[is_type(json::value_t::array)]   >> handle_array(depth))
    .when(bind()[has_field("name")]                >> handle_named_object(depth))
    .otherwise([=] {
      indent(depth);
      std::cout << "<unknown>\n";
    });
}

This formulation separates three concerns that are usually intertwined: classification, value binding, and behavior. The match expression itself is a declarative description of the dispatch strategy, not an encoded sequence of branches.

Explicit binding as a semantic boundary

One notable design constraint is that nothing binds implicitly. Binding is an explicit operation, introduced bybind(). In this example, every case binds the entire JSON value as a single unit and passes it to the handler.

This constraint is deliberate. It establishes a clear semantic boundary: matching determines whether a case applies, binding determines what data becomes available, and handlers are free to ignore or consume that data as needed. Guards are evaluated only after binding, ensuring that predicates operate on concrete values rather than symbolic placeholders.

As a result, handler signatures are stable and predictable. Each handler in this example receives exactly one argument, const json&, regardless of how complex the matching condition is.

Guards as semantic constraints

Predicates such as is_type and has_field are ordinary functions returning callables:

inline auto is_type(json::value_t t) {
  return [=](const json& j) { return j.type() == t; };
}

inline auto has_field(const std::string& key) {
  return [=](const json& j) {
    return j.is_object() && j.contains(key);
  };
}

Within the match expression, however, these predicates serve a semantic role rather than a control-flow one. A guard refines the meaning of a case; it does not represent an executable branch. Read declaratively, a case states: bind the subject, then accept this case only if it satisfies this constraint.

This distinction becomes increasingly important as predicates grow more complex or are reused across multiple cases. The match expression remains a description of intent, rather than an encoded decision tree.

Handlers as isolated effects

Handlers are intentionally free of classification logic. They perform output, recursion, or side effects, but they do not decide whether they should run.

For example, the null handler does not even consume the bound value:

inline auto print_null(int depth) {
  return [=](auto&&...) {
    indent(depth);
    std::cout << "null\n";
  };
}

The handler’s signature reflects its intent: it responds to a semantic category, not to a specific data shape. This decoupling allows handlers to evolve independently of the matching structure and makes it clear which part of the system is responsible for which decision.

Recursive structure without indirection

Recursive traversal emerges naturally from this formulation. Arrays and objects simply invoke the same dispatcher on their elements, without requiring auxiliary state or visitor hierarchies.

inline auto handle_array(int depth) {
  return [=](const json& arr) {
    indent(depth);
    std::cout << "array [" << arr.size() << "]\n";
    for (const auto& v : arr) {
      parse_json(v, depth + 1);
    }
  };
}

The recursion is explicit, local, and unsurprising. There is no hidden control flow and no implicit coupling between traversal and dispatch strategy.

Why this structure scales

The advantage of this approach is not syntactic novelty. It lies in the discipline it enforces. Classification is localized to patterns, semantic constraints are expressed as guards, and behavior is confined to handlers. As new cases are introduced—additional structural distinctions, schema-like checks, or specialized interpretations—the match expression grows horizontally rather than becoming more deeply nested.

The result is code that remains readable as a description of semantics, even as complexity increases.

Toward structural extraction

In this example, handlers inspect JSON values internally after binding. A natural extension is an extractor pattern: a pattern that validates structure and binds subcomponents directly. In a JSON context, such a pattern could match an object with specific fields and bind those fields as independent values.

This would move structural decomposition out of handlers and into the pattern layer itself, further clarifying the intent of each case. The current formulation already makes this extension straightforward, because matching, binding, and handling are explicitly separated.

Closing remarks

This JSON dispatcher is small by design, but it is not a toy example. It demonstrates how pattern matching can serve as a control-flow language embedded in C++, even in the absence of native language support. By treating JSON as a semantic sum type and making dispatch structure explicit, the resulting code becomes easier to extend, audit, and reason about.

The full implementation, including all predicates and handlers, is available at
https://github.com/sentomk/patternia/tree/main/samples/json_dispatch .

Patternia - A zero-overhead pattern matching library for C++ with powerful features like generics and structural binding.

sentomk — Mon, 15 Dec 2025 17:43:12 +0000

Patternia is a high-performance, zero-overhead pattern matching library for C++ that enables developers to express complex conditional logic in a concise and type-safe manner. It provides a comprehensive system for pattern matching, including support for structural patterns, value-based conditions, and type-safe evaluation. The library allows for seamless integration with modern C++ features like lambdas and templates, providing a powerful tool for working with complex data structures without incurring performance costs. Patternia is designed to help you write clean, efficient, and maintainable code for both simple and complex pattern matching tasks.

To explore how Patternia can be used, check out the sample code at Patternia Samples.

A pattern matching DSL for modern C++

sentomk — Sat, 08 Nov 2025 10:11:31 +0000

Hey everyone! 👋
This is my first time posting about my open-source project here — it’s called Patternia, a header-only compile-time pattern-matching DSL for modern C++.

It provides a clean and expressive syntax for writing match expressions, all evaluated entirely at compile time with zero runtime overhead.

🔗 GitHub

I’d love to hear your feedback — especially on performance, syntax feel, and any compiler corner cases you might find.

More updates are coming soon as I keep tuning and polishing the internals 👻👻