惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
Microsoft Azure Blog
Microsoft Azure Blog
aimingoo的专栏
aimingoo的专栏
Vercel News
Vercel News
U
Unit 42
L
LangChain Blog
J
Java Code Geeks
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
The Cloudflare Blog
F
Fortinet All Blogs
小众软件
小众软件
I
InfoQ
P
Proofpoint News Feed
D
DataBreaches.Net
Martin Fowler
Martin Fowler
H
Help Net Security
T
Tailwind CSS Blog
N
Netflix TechBlog - Medium
有赞技术团队
有赞技术团队
Y
Y Combinator Blog
Recent Announcements
Recent Announcements
B
Blog RSS Feed
酷 壳 – CoolShell
酷 壳 – CoolShell
B
Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Crossword helper internals: regex vs trie for pattern mat...
Dean Gilley · 2026-04-24 · via DEV Community

Crossword helper internals: regex vs trie for pattern matching

If you’ve ever spent a Sunday morning staring at a crossword puzzle, you know the frustration of having a word like C_A_E and absolutely no idea what fits. As developers, our first instinct is to build a tool to solve it. But when you move from a simple script to a production-grade word finder, you quickly hit a wall: how do you search a dictionary of 100,000+ words efficiently?

I recently spent some time refactoring a crossword solver, and I learned that the choice between a Regex-based approach and a Trie-based approach is a classic study in the trade-off between memory, startup time, and query latency.

The Regex Approach: The "Quick and Dirty"

The most intuitive way to solve C_A_E is to convert the pattern into a Regular Expression. You replace the underscores with a wildcard (like .) and anchor the string.

import re

def find_with_regex(pattern, dictionary):
    # Convert C_A_E to ^c.a.e$
    regex = re.compile(f"^{pattern.replace('_', '.')}$", re.IGNORECASE)
    return [word for word in dictionary if regex.match(word)]

Enter fullscreen mode Exit fullscreen mode

Why it works

It’s incredibly simple. You don’t need to pre-process your data, and the code is readable. If you are building a small tool or a quick prototype, this is the way to go.

The bottleneck

The problem is that re.match is an $O(n)$ operation relative to the size of your dictionary. For every single query, your CPU has to iterate through every word in your list, compile the regex, and perform the match. On a dictionary of 100,000 words, a single lookup takes roughly 50ms. That might sound fast, but if you’re building a site like a2zwordfinder.com, where users expect instant, type-ahead results, that latency adds up quickly.

The Trie Approach: The "Spatial Index"

A Trie (or prefix tree) is a tree-like data structure where each node represents a character. By traversing the tree, you can prune entire branches that don't match your pattern.

To handle crossword patterns, we don't just store words; we store them in a way that respects position. If we are looking for C_A_E, we only traverse the branch starting with C, then skip the next node (the wildcard), move to A, and so on.

class TrieNode:
    def __init__(self):
        self.children = {}
        self.is_word = False

def search_trie(node, pattern, index=0):
    if index == len(pattern):
        return [[]] if node.is_word else []

    char = pattern[index]
    results = []

    if char == '_':
        for child_char, child_node in node.children.items():
            for res in search_trie(child_node, pattern, index + 1):
                results.append([child_char] + res)
    elif char in node.children:
        for res in search_trie(node.children[char], pattern, index + 1):
            results.append([char] + res)

    return results

Enter fullscreen mode Exit fullscreen mode

Why it wins

The Trie turns your search into an $O(k)$ operation, where $k$ is the length of the pattern. Because you are only visiting nodes that could possibly match, you aren't scanning the entire dictionary.

In my benchmarks, once the Trie is built (which takes about 200ms on startup), the query time drops to roughly 0.1ms. That is a 500x speedup over the regex approach.

The Trade-off: When to use which?

Choosing between these two isn't about which is "better," but about the constraints of your application.

Use Regex if:

  • Memory is tight: A Trie can consume significant RAM because of the overhead of storing thousands of node objects.
  • Your dictionary is small: If you’re only searching through a few thousand words, the overhead of building a Trie isn't worth the performance gain.
  • You need flexibility: Regex allows for complex patterns (like "starts with C, ends with E, and contains at least two vowels") that are much harder to implement in a standard Trie.

Use a Trie if:

  • You are building a high-traffic service: If you look at professional-grade tools like Puzzle Depot, they prioritize sub-millisecond response times. A Trie is essential for providing a snappy user experience.
  • You have a static dictionary: If your word list doesn't change often, you can build the Trie once at server startup and keep it in memory.
  • You need "Search-as-you-type": The speed of the Trie allows you to filter results in real-time as the user types, which is a massive UX win.

Final Thoughts

Building a crossword helper taught me that performance optimization is rarely about finding the "fastest" algorithm and almost always about understanding the lifecycle of your data.

If you’re just starting out, stick with Regex. It’s clean, maintainable, and gets the job done. But if you find yourself hitting that 50ms latency wall and your users are starting to notice, it’s time to reach for a Trie. It’s a bit more work to implement, but the performance gains are undeniable.

Have you built a word-finding tool? Did you go the Regex route or build a custom index? Let me know in the comments!