Crate for storing many immutable strings in one buffer with minimal resource usage.

Designed to minimize:

• memory overhead (single byte buffer + compact offsets)
• CPU overhead (cheap index-based lookups)
• binary size overhead (no panics on insertion, avoiding backtrace overhead)

See full crate docs for more details. Below is just a sneak peek.

For a companion blog post with additional design insights and real-world context, see Sometimes I Need to Store a Lot of Strings Efficiently, So I Built lite-strtab.

[dependencies]
lite-strtab = "0.1.0"

use lite_strtab::StringTableBuilder;

let mut builder = StringTableBuilder::new();
let id = builder.try_push("hello").unwrap();
let table = builder.build();

assert_eq!(table.get(id), Some("hello"));

See full crate docs for more details. This page is a summary.

Measured on Linux with glibc malloc using malloc_usable_size (capturing allocator block sizes including alignment overhead).

How to read these tables:

• Total = Heap allocations + Distributed fields + One-time metadata
• Distributed fields = string references distributed across fields/structs (e.g. String, Box<str>, StringId<u16>)
• in these results, lite-strtab uses StringId<u16>

This keeps the comparison close to real application layouts while still keeping the baseline rows readable.

YakuzaKiwami (4,650 game file paths, 238,109 bytes):

EnvKeys (109 environment variable names, 1,795 bytes):

ApiUrls (90 API endpoint URLs, 3,970 bytes):

For complete comparisons across all datasets and full breakdown details, see full crate docs.

Summary: lite-strtab uses 20-55% less memory than the standard methods. Generally the smaller the strings, the better the savings.

In this benchmark we sequentially read all of the 4,650 strings (238,109 bytes) and hash them with AHash to simulate a realistic workload that involves reading the strings.

Reproduce with cargo bench --bench my_benchmark. Linux glibc. cargo 1.95.0-nightly (fe2f314ae 2026-01-30).

In summary, actual read performance on real data is within margin of error.

The overhead of looking up a string by ID is negligible. Any difference you see is mostly due to run to run variation.

I've experimented with data alignment too, but saw no notable difference in practice after aligning to usize boundaries to avoid reads across word boundaries. There may be some in random access patterns; I've only benched sequential here.

Instruction count to get &str, x86_64, release mode:

Overhead of processing the data largely dominates; so the difference here is negligible.

MIT