{"slug": "zigrep-a-fast-zero-libc-grep-alternative-written-in-zig-0-16", "title": "ZiGrep — A fast, zero-libc grep alternative written in Zig 0.16", "summary": "ZiGrep, an MIT-licensed text search tool built in Zig 0.16 by developer DannyBaanks, beat ripgrep on two of three Linux benchmarks: 85.31 ms versus 108.67 ms for a literal search over a 655 MB repository and 95.63 ms versus 120.33 ms for a regex search, while losing on a 131 MB synthetic corpus at 47.57 ms versus 37.93 ms. ZiGrep runs on Linux via direct syscalls without libc and natively on Windows, using getdents64 and openat traversal, work-stealing concurrency with a zero-thread fast path, SIMD literal matching, and a Thompson NFA with lazy DFA caching. The author is now exploring an agent-oriented interface with JSONL output, batched searches, explicit output budgets and verifiable result metadata, but stated the question of whether such a tool helps agents finish tasks with fewer tool calls and tokens is \"a research direction, not a performance claim.", "body_md": "ZiGrep is an open-source text search tool I’ve been building in Zig 0.16. It’s MIT-licensed and currently runs on Linux and Windows.\n\nIt actually started as an experiment. I wanted to see how far I could push filesystem traversal, SIMD scanning, and concurrency using Zig. One thing led to another, and eventually I started thinking about something a bit different: what would a search tool look like if it were designed for both developers and autonomous coding agents?\n\nThat’s the direction I’m exploring now.\n\nOn Linux, ZiGrep uses direct syscalls without relying on libc. On Windows, it runs natively through platform APIs, so there’s no need for WSL.\n\nI’ve been experimenting with quite a few approaches, and some have worked better than others.\n\n**Filesystem traversal:** Using Linux’s `getdents64` and `openat` directly to cut down on directory traversal overhead.\n\n**Concurrency:** A work-stealing architecture for parallel searches, plus a zero-thread fast path when the directory tree is small enough that spawning workers would just add overhead.\n\n**SIMD:** Vectorized literal matching with a rarest-byte strategy.\n\n**Regex:** A Thompson NFA with lazy DFA caching, avoiding the catastrophic backtracking problem.\n\n**Deterministic results:** I wanted parallel execution without unpredictable output ordering, so I’ve been working with sequence tickets and pruning to keep results ordered.\n\n**Befunge-inspired traversal:** This one’s a little unusual. I’ve also been experimenting with filesystem navigation inspired by Befunge’s directional instructions. Mostly because I was curious whether the idea could be useful outside an esoteric language.\n\n**`io_uring`:** There’s also an optional experimental Linux backend using native asynchronous I/O.\n\nOne thing I care about is being able to verify that the optimizations aren’t changing the actual search results. I’ve been running differential tests against GNU grep and ripgrep, along with conformance checks.\n\nMaking something fast is interesting, but making it fast while still returning the right results is the part that really matters to me.\n\nHere are a few results from my Linux tests:\n\n| Workload | ZiGrep | ripgrep | \n|---|---|---|\n| 655 MB repository, literal search | 85.31 ms | 108.67 ms | \n| 655 MB repository, regex search | 95.63 ms | 120.33 ms | \n| 131 MB synthetic corpus | 47.57 ms | 37.93 ms | \n\nThese are my own project benchmarks, not independent results. I ran them on a Linux machine with 12 CPU threads, using repeated and interleaved runs to make the comparisons more useful.\n\nAs you can see, ZiGrep isn’t faster in every case.\n\nAnd that’s fine! I’m not trying to claim that I’ve somehow beaten ripgrep at everything. I’m more interested in figuring out *why* certain approaches perform better on some workloads and worse on others.\n\nThe slower cases are often just as interesting as the faster ones.\n\nI’ve documented the methodology and more results in [PRUEBAS.md](https://github.com/DannyBaanks/ZiGrep/blob/main/PRUEBAS.md).\n\nLately, I’ve been thinking a lot about how coding agents interact with search tools.\n\nMost search utilities are designed around a human reading the output. But an AI agent has different constraints. It might need structured results, predictable output sizes, or enough metadata to verify what it received without making several additional tool calls.\n\nSo I’m experimenting with a more agent-friendly interface: JSONL output, batched searches, explicit output budgets, and verifiable result metadata.\n\nThe question I’m trying to answer is pretty simple:\n\n**Can a search tool designed specifically for agents help them complete more tasks correctly, using fewer tool calls, fewer tokens, and less time?**\n\nI don’t have enough evidence to answer that yet. It’s a research direction, not a performance claim, and I want to test it properly against existing tools.\n\nI’m also deliberately keeping natural-language interpretation outside ZiGrep. I don’t want the search engine itself guessing what the user meant. I’d rather have it remain a deterministic component that other systems can use.\n\n**Zig 0.16.0**\n\nI also want to be transparent about how I’m building this.\n\nI use AI coding agents extensively. They help with implementation, debugging, reviews, and planning experiments.\n\nMy part is primarily the system architecture, figuring out what I want to explore, making design decisions, coordinating the agents, and checking whether the results actually hold up through testing.\n\nSo no, I’m not going to pretend I manually typed every line of code.\n\nThis is a project built through human-directed collaboration with AI, and I’m comfortable saying that openly.\n\nI think being clear about that matters, especially when discussing technical results. Regardless of who wrote a particular piece of code, the behavior and performance claims still need to be tested and reproducible.\n\nI’m still learning Zig, and that’s honestly a big part of why I’m sharing this.\n\nI’d really appreciate feedback from people with more experience, especially around concurrency, filesystem traversal, SIMD, portability, and benchmarking.\n\nIf you spot something questionable in the design, a better way to approach a problem, or an experiment worth trying, I’d love to hear about it.\n\nThanks for checking it out!", "url": "https://wpnews.pro/news/zigrep-a-fast-zero-libc-grep-alternative-written-in-zig-0-16", "canonical_source": "https://ziggit.dev/t/zigrep-a-fast-zero-libc-grep-alternative-written-in-zig-0-16/18308#post_1", "published_at": "2026-11-11 02:05:26+00:00", "updated_at": "2026-11-11 02:22:46.774317+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-tools"], "entities": ["ZiGrep", "Zig 0.16", "DannyBaanks", "ripgrep", "GNU grep", "Linux", "Windows"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/zigrep-a-fast-zero-libc-grep-alternative-written-in-zig-0-16", "markdown": "https://wpnews.pro/news/zigrep-a-fast-zero-libc-grep-alternative-written-in-zig-0-16.md", "text": "https://wpnews.pro/news/zigrep-a-fast-zero-libc-grep-alternative-written-in-zig-0-16.txt", "jsonld": "https://wpnews.pro/news/zigrep-a-fast-zero-libc-grep-alternative-written-in-zig-0-16.jsonld"}}