I thought about trying to measure the input on the real-world code that I have to use it in (specifically, decoding email messages). The challenge of trying to do base64 decoding fast there is that you generally have to ignore whitespace characters (and possibly other junk as well).<p>The code implementation here clearly requires that all the extraneous stuff get kicked out and the resulting string be compacted, an operation whose overhead by itself could easily negate merely a 46% gain; it&#x27;s hard to see how it could be modified to make the stateful decisions while still keeping the tight gain. I also have a sneaking suspicion that the improved scalar version might turn out to be worse in real-world systems because the 4KiB table would cause L1 cache thrashing if you&#x27;re doing lots of small base64 decodings followed by later processing (e.g., string conversion).<p>So the real problem is that the measurement is done in a way which is different enough from real-world scenarios that it&#x27;s questionable if any speedup is actually achievable in those scenarios, let alone one as significant as a 46% gain. It&#x27;s easy to be fast if you ignore having to do it correctly.