> So I heavily experimented with squeezing performance out of a JS-based trie-implementation for LZString. Incidentally, I did write a JS/WASM version of LZ4 b

> So I heavily experimented with squeezing performance out of a JS-based trie-implementation for LZString. Incidentally, I did write a JS/WASM version of LZ4 block encoding[1] (also used in uBO). I do wonder if it could be of interest for the LZString project. My understanding is that the output of LZ4 compression would need to be further processed to make it JS string-friendly (for localStorage purpose). Maybe worth exploring if even with that extra step[2], the performance gain if any is worth it? [1] https://github.com/gorhill/lz4-wasm https://github.com/gorhill/lz4-wasm [2] Encode 7 bytes into 8 valid ASCII characters?