This can consistently get 25% shorter encoded data than substitution-based encoders out there (what griffpatch and most of scratch uses). My previous bottleneck was a^b running constantly. By loading the powers of the length of the codec beforehand, you don't need to compute them while encoding!!! The only problem for now is that there are inconsistencies sometimes with larger strings, probably because of how much math JavaScript has to handle... this can be improved by putting most used chars at the beginning of the codec and least used chars at the end... to make this possible i scraped 100k griffpatch followers to get the most to least frequently used letters in usernames and here are my results: ['a', 'e', 'o', 'r', 'i', 'n', 't', 's', 'l', 'm', 'c', 'h', 'u', 'd', '1', '_', 'g', '2', 'y', 'k', 'b', '0', 'p', '3', '-', 'f', '4', '5', 'w', '7', '9', 'v', '6', '8', 'j', 'z', 'x', 'q'] the letters paired up with frequencies can be found inside the project as a comment (because for some reason filterbot thinks it has a bad word idk why)
This is an explanation of how it works: Instead of substituting letters for numbers, it treats the letters as numbers in a custom base e.g. base²⁶ for the alphabet, then converts it to base¹⁰ and vice versa to decode. This is a lot better than normal substitution encode / decode because the encoding size increases logarithmically with longer inputs as opposed to simple letter to number substitution which increases linearly in size. - basically the more you encode the bigger the difference you'll see! Also the smaller the codec the more efficient the conversion, so keep that in mind and don't add any characters that you don't need. TLDR; 1. the longer the string, the more efficient encoding is 2. the smaller the 'codec' the more efficient the encoding is
