DEV Community: sentomk

How We Made a 128-Arm Pattern Match Run 10 Faster

sentomk — Fri, 08 May 2026 08:39:22 +0000

How We Made a 128-Arm Pattern Match Run 10× Faster

The 128-branch dispatch problem, and the compile-time optimization system that solved it.

Pattern matching is coming to C++ — eventually. C++26 might bring it. But if you're writing C++17 today and need to match on variants, enums, or arbitrary values with guards, destructuring, and combinators, you're on your own.

I've been building Patternia, a C++17 header-only pattern matching library, for the past year. The API is simple enough:

#include <ptn/patternia.hpp>
using namespace ptn;

auto result = match(subject) | on(
    val<Status::Ready>     >> []{ return "ready"; },
    val<Status::Pending>   >> []{ return "pending"; },
    is<Error>(ds(status))  >> [](int s){ return "error: " + std::to_string(s); },
    _                      >> []{ return "unknown"; }
);

Clean. But the API isn't the hard part. The hard part is making it fast.

The Problem

When you write a pattern match with 128 cases (not unusual for protocol parsers or command dispatchers), every on() call constructs those 128 case objects — guards, destructuring patterns, combinators — every single time the match is evaluated.

The naive approach: 10.79 nanoseconds per call.

A hand-written switch with 128 branches: 1.09 nanoseconds per call.

That's a 10× gap. If your library is slower than the code it replaces, nobody will use it.

The Solution: Automatic Dispatch Plan Selection

The core insight is that at compile time, the library knows everything about the patterns — which ones are compile-time constants, which ones match variant types, which ones have guards. So why not let the compiler pick the optimal dispatch strategy?

Patternia does this with a six-tier dispatch plan hierarchy, selected at compile time via dispatch_plan_selector:

1. static_literal_dense   — O(1) array lookup for val<V> compile-time values
2. literal_runtime_dense  — O(1) for runtime lit() values
3. literal_linear         — Direct dispatch for integral/enum subjects
4. variant_simple         — Precomputed case-index table by variant alt
5. variant_alt_bucketed   — Binary search over alt-bucketed cases
6. sequential             — Linear fallback

The selector analyzes the pattern set and picks the best strategy at compile time — no runtime overhead for the decision:

template <typename AnalysisResult>
struct dispatch_plan_selector {
    static constexpr dispatch_plan_kind kind =
        analysis_t::can_use_static_literal_dispatch
            ? dispatch_plan_kind::static_literal_dense
            : (analysis_t::can_use_runtime_literal_dense_dispatch
                   ? dispatch_plan_kind::literal_runtime_dense
                   : (analysis_t::can_use_simple_literal_dispatch
                          ? dispatch_plan_kind::literal_linear
                          : (analysis_t::can_use_simple_variant_dispatch
                                 ? dispatch_plan_kind::variant_simple
                                 : (analysis_t::can_use_variant_alt_dispatch
                                        ? dispatch_plan_kind::variant_alt_bucketed
                                        : dispatch_plan_kind::sequential))));
};

Each tier applies density heuristics to decide whether to engage. For example, static_literal_dense only activates when the value span is at most 4× the number of literal cases — ensuring the lookup table isn't too sparse. Tuning parameters are baked in:

k_static_literal_dense_dispatch_max_cases   = 256;
k_static_literal_dense_dispatch_max_span    = 512;
k_static_literal_dense_dispatch_max_density = 4;
k_runtime_literal_dense_dispatch_max_cases  = 256;
k_runtime_literal_dense_dispatch_max_span   = 512;
k_runtime_literal_dense_dispatch_max_density = 8;

The `[[no_unique_address]]` Bug

Here's where it got weird. The optimization system checks whether a pattern type is "cacheable" — empty types can be skipped, reducing the case construction overhead. It used std::is_empty for this check.

One pattern type, static_literal_pattern, holds a comparator:

template <auto V, typename Cmp = std::equal_to<>>
struct static_literal_pattern : base::pattern_base<static_literal_pattern<V, Cmp>> {
  [[no_unique_address]] Cmp cmp{};
  // ...
};

std::equal_to<> is technically an empty type. We annotated it with [[no_unique_address]]. But GCC applied the attribute inconsistently — sometimes the member was optimized away, sometimes not. When GCC left it in, std::is_empty returned false for the pattern type, and the cache path was silently skipped.

The fix: replace std::is_empty with a sizeof <= 1 heuristic. Works consistently across GCC, Clang, and MSVC.

Finding this bug required reading the generated assembly for a dozen compiler versions. The lesson: [[no_unique_address]] is a hint, not a guarantee.

Results

With automatic dispatch plan selection, the 128-branch match drops from 10.79 ns to 1.13 ns — within 4% of a hand-written switch (1.09 ns):

Approach	Latency
Raw `on()` (naive)	10.79 ns
PTN_ON macro (manual cache)	1.16 ns
Auto-cache (this work)	1.13 ns
Hand-written switch	1.09 ns

The key win: automatic optimization means users get the fast path without knowing dispatch plans exist. They just write match(subject) | on(...) and the compile-time analyzer does the rest.

Real-World Benchmarks

Beyond the 128-branch microbenchmark, Patternia holds its own in realistic scenarios:

Scenario	Patternia	Baseline	Result
Command parser	1.790 ns	Switch (2.258 ns)	+26% faster
Protocol router	1.628 ns	IfElse (1.866 ns)	+14% faster
Variant mixed	1.997 ns	std::visit (1.991 ns)	Tied

How It Compares

Patternia isn't the only C++ pattern matching library. But it brings a few things the others don't:

Feature	Patternia	matchit.cpp	Mach7
Pipeline syntax	✅	❌	❌
Compile-time dispatch optimization	✅	Limited	❌
Structural bindings	✅	❌	❌
Guard expressions	✅	❌	❌
Pattern combinators (any/all/neg)	✅	❌	❌
C++ standard	C++17	C++17	C++14
Header-only	✅	✅	✅

The automatic dispatch optimization is the differentiator. Other libraries can match — Patternia matches fast.

Try It

The library is a single header include away:

# CMake FetchContent, vcpkg, or just copy the headers
git clone https://github.com/sentomk/patternia

#include <ptn/patternia.hpp>
using namespace ptn;

// Your first pattern match, automatically optimized
auto result = match(value) | on(
    val<1>    >> []{ return "one"; },
    val<2>    >> []{ return "two"; },
    is<std::string>(ds(s)) >> [](auto& s){ return s; },
    _         >> []{ return "other"; }
);

The compile-time optimizer picks the right dispatch strategy. You don't have to think about it.

Patternia on GitHub — 179 stars, 438 commits, C++17 header-only.

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 👻👻