String-Pool Packer

About This Tool

Firmware that ships UI text in several languages usually stores it as a 2-D table of const char* pointers — one per (language × string ID) cell. On a 32-bit MCU each pointer is 4 bytes of pure index overhead, before a single character of text. This tool shows what you save by switching to a single packed string pool plus a table of 2-byte uint16 offsets, with identical strings deduplicated and suffixes tail-merged into longer strings.

It is the interactive companion to the article

.

Two modes

• Lines — paste strings one per line; each line is one index entry (a single language × ID cell).

• CSV — the real firmware layout: a header id,en,es,… and one row per string ID, one column per language. Every cell becomes an index entry, and an identifier × language lookup simulates the firmware’s tr(): pick an ID and a language and the tool shows the resolved offset and string (gen::string(lang, id) → pool + offset).

How do I use it?

1. Choose Lines or CSV mode and paste your data (use Load example for a starting point).

2. Pick the pointer width for your target (4 bytes for a 32-bit MCU, 8 bytes for a 64-bit host).

3. Read the comparison: index-table bytes, string-blob bytes, and the total for both the pointer-table and the packed-pool approach.

4. Scan the per-string breakdown — including each string’s byte offset — to see which strings were deduplicated and which were tail-merged into a longer string (their offset points partway into that longer entry).

What does it compute?

• Index table — entries × 4 B (pointers) versus entries × 2 B (uint16 offsets). This halving is the structural win no linker can do for you.

• Dedup — identical strings (shared across languages, like “OK”) are stored once.

• Tail-merge — a string that is the suffix of another reuses the longer string’s bytes (placed longest-first), exactly what the build-time generator does.

• uint16 guard — flags when the pool grows past 64 KiB, at which point offsets no longer fit in a uint16.

• Retrieval — every string, stored or tail-merged, is read by pool + offset. A tail-merged string is never stored separately; its offset simply lands inside a longer entry, so lookup stays O(1) and identical for every string.

Is my data private?

All parsing, deduplication, tail-merging, and byte counting happen entirely in your browser. Nothing you type is transmitted to any server.