Strings are the first fundamental data type every programming language implements in software rather than hardware — the closest CPUs come to a "find substring" instruction is x86's PCMPISTRI, which is too slow and too narrow to build a library on, and nothing ships a "compute string hash" instruction at all. So most string-processing code still looks like for (i = 0; i < length; ++i) if (text[i] == 'x') … — a tangle of loops, branches, and per-character lookups, where the surrounding control flow often costs more than the character-level logic itself, whether the text is ASCII or UTF-8 encoded Unicode. Worse, chewing through one byte or codepoint at a time squanders the hardware: a modern CPU carries dozens of 16-64 byte architectural registers, and hundreds of physical ones to feed out-of-order execution. StringZilla reaches for those SIMD and SWAR instructions directly, offering one of the widest, fastest, and most portable collections of text-processing primitives anywhere.

StringZilla is the GodZilla of string libraries, accelerating exact and fuzzy matching, hashing, edit distances, sorting, segmentation, and even random-string generation, with allocation-free lazily-evaluated iterators throughout.

• It can be 3x faster than LibC doing substring search on Arm servers, and 9x on Apple Silicon, where the system strstr is weaker.
• It can be 10-70x faster than ICU, both ICU4C and its Rust successor ICU4X, in UTF-8 handling, case folding, segmentation, and tokenization.
• It can be over 10x faster than NVIDIA's own libraries for on-GPU Levenshtein, NW, and SW edit distances.
• It comes with built-in custom WebAssembly backend for sandboxed browser, DBMS, & LLM environments, custom RVV backend for RISC-V CPUs, PowerPC backend for IBM Power servers, LoongArch for Chinese domestic chips, and more!

Reach for it from your language of choice:

• 🐂 C: Upgrade LibC's <string.h> to <stringzilla/stringzilla.h> in C 99
• 🐉 C++: Upgrade STL's <string> to <stringzilla/stringzilla.hpp> in C++ 11
• 🧮 CUDA: Process in-bulk with <stringzillas/stringzillas.cuh> in CUDA C++ 17
• 🐍 Python: Upgrade your str to faster Str
• 🦀 Rust: Use the StringZilla traits crate
• 🦫 Go: Use the StringZilla cGo module
• 🍎 Swift: Use the String+StringZilla extension
• 🟨 JavaScript: Use the StringZilla library
• 💜 C#: Zero-copy over ReadOnlySpan<byte>, NativeAOT-friendly
• ☕ Java: Pure FFM API over MemorySegment, no JNI
• 🐚 Shell: Accelerate common CLI tools with sz- prefix
• 📚 Researcher? Jump to Algorithms & Design Decisions
• 💡 Thinking to contribute? Look for "good first issues"
• 🤝 And check the guide to set up the environment
• Want more bindings or features? Let me know!

Who is this for?

• For data-engineers parsing large datasets, like the CommonCrawl, RedPajama, or LAION.
• For software engineers optimizing strings in their apps and services.
• For bioinformaticians and search engineers looking for edit-distances for USearch.
• For DBMS devs, optimizing LIKE, ORDER BY, and GROUP BY operations.
• For hardware designers, needing a SWAR baseline for string-processing functionality.
• For students studying SIMD/SWAR applications to non-data-parallel operations.

Performance

Throughput and timings on two CPUs and one GPU, grouped by operation. Only the languages that ship a counterpart appear under each heading. StringZilla.C is the C kernel called directly; StringZilla.Py is the same kernel through the CPython binding, so the gap between them is the cost of crossing the interpreter boundary.

                                                      Xeon4    M5 Pro        H100
─────────────────────────────────────────────────────────────────────────────────
Unicode case-insensitive substring search  (GB/s)
  Python          icu.StringSearch                     0.06      0.15
  StringZilla.C   sz_utf8_uncased_search              13.16      9.30
  StringZilla.Py  sz.utf8_uncased_search              12.40      9.19
Find the first occurrence of a random word, ≅ 5 bytes  (GB/s)
  LibC            strstr                               21.3       3.5
  STL C++         std::string::find                     9.1      10.9
  Python          str.find                              2.5       3.1
  StringZilla.C   sz_find                              21.0      37.1
  StringZilla.Py  sz.find                              18.6      33.4
Split lines separated by \n or \r  (GB/s)
  LibC            strcspn                               9.2       3.8
  STL C++         std::string::find_first_of            1.1       4.1
  Python          re.finditer                          0.32      0.64
  StringZilla.C   sz_find_byteset                      13.8      23.7
  StringZilla.Py  sz.split_byteset_iter                11.2      21.7
Levenshtein distances, ≅ 100 byte DNA, one core  (MCUPS)
  Python          rapidfuzz.process.cdist             4,970    18,370
  StringZilla.C   szs_levenshtein_distances          15,680    22,844   5,980,110
  StringZilla.Py  szs.LevenshteinDistances           14,130    21,930   4,074,700
Needleman-Wunsch scores, ≅ 1 KB DNA, one core  (MCUPS)
  Python          Bio.Align.PairwiseAligner.score       430       870
  StringZilla.C   szs_needleman_wunsch_scores        12,000     1,267     701,760
  StringZilla.Py  szs.NeedlemanWunschScores          10,730     1,060     700,900

Treat these as a first impression, not a benchmark suite. The Unicode numbers were obtained on a 128 MB slice of multilingual XLSum; the similarity rows on synthetic DNA strings. Xeon4 is an Intel Sapphire Rapids with GCC and glibc, M5 Pro an 18-core Apple Silicon with Apple clang and libc++, H100 an Nvidia Hopper GPU. The two CPUs therefore differ in standard library as much as in ISA, which is most of the gap in the strstr, std::string::rfind, and bytes.translate rows; the StringZilla rows build from the same source on both. These will not reproduce exactly; the links below carry the methodology and the per-library breakdowns.

Most StringZilla modules ship ready-to-run benchmarks for C, C++, Python, and more. Grab them from ./scripts, and see CONTRIBUTING.md, test/README.md, and bench/README.md for instructions. For wider head-to-heads against Rust and Python favorites, browse the StringWars repository. To inspect collision resistance and distribution shapes for our hashers, see HashEvals.

Why StringZilla

There are several other excellent libraries with overlapping subsets of operations and somewhat different design philosophies. LibC obviously provides a good baseline for basic memory operations, but its APIs vary widely in quality, and its Arm implementations often trail its x86 ones. ICU and ICU4X implement the Unicode standard to a letter, but don't exploit hidden invariants in the Unicode ruleset to vectorize those operations. RapidFuzz comes with a very good set of string-similarity algorithms and is already well vectorized on CPUs, but leaves batched cross-products symmetries and massive GPU speedups on the table. xxHash and aHash provide great non-cryptographic hashes, but may not cover all of the hashing use cases, or leverage the wider AES and predicated instructions available on modern CPUs.

Because StringZilla mirrors the familiar standard APIs, adoption is mostly a search-and-replace.

                           Standard                  StringZilla
─────────────────────────────────────────────────────────────────────────────────
Python
  Find a substring         "...".find(x)             sz.find("...", x)
  Sort strings             sorted(items)             sz.Strs(items).sorted()
  Split on a separator     "...".split(sep)          sz.Str("...").split(sep)
  Case-fold for matching   "...".casefold()          sz.utf8_uncased_fold("...")
  Streaming SHA-256        hashlib.sha256()          sz.Sha256()
C++
  Find a substring         std::string::find         sz::string::find
  Sort a collection        std::sort of indices      sz::argsort
  Intersect string sets    std::set_intersection     sz::try_intersect
  Hash map, string keys    std::unordered_map<K, V>  sz::hash + sz::equal_to

Functionality

StringZilla is compatible with most modern CPUs, and provides a broad range of functionality. It's split into 2 layers:

1. StringZilla: single-header C library and C++ wrapper for high-performance string operations.
2. StringZillas: parallel CPU/GPU backends used for large-batch operations and accelerators.

Having a second C++/CUDA layer greatly simplifies the implementation of similarity scoring and fingerprinting functions, which would otherwise require too much error-prone boilerplate code in pure C. Both layers are designed to be extremely portable:

• across both little-endian and big-endian architectures.
• across 32-bit and 64-bit hardware architectures.
• across operating systems and compilers.
• across ASCII and UTF-8 encoded inputs.

Not all features are available across all bindings. Consider contributing if you need a feature that's not yet implemented.

🌳 parts are used in production. 🧐 parts are in beta. 🚧 parts are under active development, and are likely to break in subsequent releases. ✅ are implemented. ⚪ are considered. ❌ are not intended.

Quick Start

Each binding has its own install command, import line, and dedicated guide, all collected in the per-language sections below. The batch and GPU engines ship separately, as stringzillas-cpus and stringzillas-cuda on PyPI and the cpus and cuda crate features; each binding's guide covers the details.

Python

pip install stringzilla · guide: python/README.md

import stringzilla as sz
text = sz.Str("the quick brown fox")
text.find("brown")          # 10
text.split()                # Strs(['the', 'quick', 'brown', 'fox'])
sz.hash("hello")            # fast 64-bit hash

The Python package upgrades str and bytes with SIMD search, sorting, hashing, UTF-8 segmentation, and Unicode case-folding, plus the batch-parallel stringzillas engines for edit distances and rolling fingerprints.

C and C++

Header-only, or pull it in with CMake FetchContent, or find_package(stringzilla) an installed build · guides: include/stringzilla/README.md and include/stringzillas/README.md

#include <stringzilla/stringzilla.h>
sz_find(haystack, h_length, "brown", 5); // pointer to the match, or NULL

#include <stringzilla/stringzilla.hpp>
namespace sz = ashvardanian::stringzilla;
sz::string_view("the quick brown fox").find("brown"); // 10

The header-only library covers search, hashing, sorting, comparison, set intersection, memory operations, and lazy UTF-8 segmentation; the bulk and GPU engines for edit distances, alignment scores, and fingerprints live in the companion stringzillas distribution.

Rust

cargo add stringzilla · guide: rust/README.md

use stringzilla::sz;
assert_eq!(sz::find("the quick brown fox", "brown"), Some(10));
let digest = sz::hash("hello"); // fast 64-bit hash

The crate adds SIMD search, sorting, hashing, and UTF-8 segmentation to any AsRef<[u8]>, with the optional stringzillas engines for batch edit distances and rolling fingerprints.

JavaScript

npm install stringzilla · guide: javascript/README.md

import sz from "stringzilla";
sz.find(Buffer.from("the quick brown fox"), Buffer.from("brown")); // => 10n
sz.hash(Buffer.from("hello"));                                     // 64-bit BigInt

The Node-API addon runs on Node, Bun, and Deno, exposing zero-copy search, hashing, SHA-256, and Unicode case-folding over Buffer objects.

Swift

Add the Swift Package Manager dependency · guide: swift/README.md

import StringZilla
let i = "the quick brown fox".findFirst(substring: "brown") // Index of "brown"
let h = "hello".hash()                                       // fast 64-bit hash

The Foundation-free package extends String with SIMD search, comparison, hashing, Unicode case-folding, normalization, and word and line segmentation, on Linux and embedded targets as well as Apple platforms.

Go

go get github.com/ashvardanian/stringzilla/golang · guide: golang/README.md

import sz "github.com/ashvardanian/stringzilla/golang"
sz.Index("the quick brown fox", "brown") // 10
sz.Hash("hello", 0)                      // fast 64-bit hash

The cgo module exposes byte-level search, counting, checksums, SHA-256, and UTF-8 case-folding to Go.

C#

Build from source · guide: csharp/README.md · not yet on NuGet

using StringZilla;
Sz.IndexOf("the quick brown fox"u8, "brown"u8); // 10
Sz.Hash("hello"u8);                             // fast 64-bit hash

Zero-copy over ReadOnlySpan<byte> (and Unity's NativeArray<byte>); net8.0, NativeAOT-friendly. Exposes search, hashing, SHA-256, UTF-8 segmentation, case-folding, normalization, sorting, and allocation-free splitting and iteration.

Java

Build from source with mvn · guide: java/README.md · not yet on Maven Central

import com.stringzilla.StringZilla;
StringZilla.indexOf("the quick brown fox".getBytes(), "brown".getBytes());  // 10
StringZilla.hash("hello".getBytes());                                       // fast 64-bit hash

Pure Foreign Function & Memory API (JDK 22+), no JNI. Zero-copy over byte[] and MemorySegment — including Lucene BytesRef and Spark UTF8String backing memory. Lazy Iterable/Stream splitting and iteration, with zero-allocation cursors as the escape hatch.

Algorithms & Design Decisions

StringZilla aims to optimize some of the slowest string operations. Some popular operations, however, like equality comparisons and relative order checking, almost always complete on some of the very first bytes in either string. In such operations vectorization is almost useless, unless huge and very similar strings are considered. StringZilla implements those operations as well, but won't result in substantial speedups. Where vectorization stops being effective, parallelism takes over, across two layers:

• StringZilla C library w/out dependencies
• StringZillas parallel extensions:
  • Parallel C++ algorithms built with ForkUnion
  • Parallel CUDA algorithms for Nvidia GPUs
  • Parallel ROCm algorithms for AMD GPUs 🔜

Exact Substring Search

Substring search algorithms are generally divided into: comparison-based, automaton-based, and bit-parallel. Different families are effective for different alphabet sizes and needle lengths. The more operations are needed per-character - the more effective SIMD would be. The longer the needle - the more effective the skip-tables are. StringZilla uses different exact substring search algorithms for different needle lengths and backends:

• When no SIMD is available - SWAR (SIMD Within A Register) algorithms are used on 64-bit words.
• Boyer-Moore-Horspool (BMH) algorithm with Raita heuristic variation for longer needles.
• SIMD backends compare characters at multiple strategically chosen offsets within the needle to reduce degeneracy.

On very short needles, especially 1-4 characters long, brute force with SIMD is the fastest solution. On mid-length needles, bit-parallel algorithms are effective, as the character masks fit into 32-bit or 64-bit words. Either way, if the needle is under 64-bytes long, on haystack traversal we will still fetch every CPU cache line. So the only way to improve performance is to reduce the number of comparisons.

For 2-byte needles, see sz_find_2byte_serial_ in include/stringzilla/find/serial.h:

Going beyond that, to long needles, Boyer-Moore (BM) and its variants are often the best choice. It has two tables: the good-suffix shift and the bad-character shift. Common choice is to use the simplified BMH algorithm, which only uses the bad-character shift table, reducing the pre-processing time. We do the same for mid-length needles up to 256 bytes long. That way the stack-allocated shift table remains small.

For mid-length needles (≤256 bytes), see sz_find_horspool_upto_256bytes_serial_ in include/stringzilla/find/serial.h:

In the C++ Standards Library, the std::string::find function uses the BMH algorithm with Raita's heuristic. Before comparing the entire string, it matches the first, last, and the middle character. Very practical, but can be slow for repetitive characters. Both SWAR and SIMD backends of StringZilla have a cheap pre-processing step, where we locate unique characters. This makes the library a lot more practical when dealing with non-English corpora.

The offset selection heuristic is implemented in sz_locate_needle_anomalies_ in include/stringzilla/find/serial.h:

All those, still, have