Converting vector of bytes to base64 string and back

Here are a few suggestions:

1. Don't write this

Many before you have needed, and gotten, a fast Base64 decoder. Why should you write this yourself? You don't seem to have a special twist on the decoding/encoding - unless you want "base85 decoding", a term I'm not quite sure I understand.

Specifically, here is a nice treatment of the subject (although still far from the optimum):

Fast Base64 encode and decode

(and see also the suggestion in the comments there - by now only available on archive.org)

2. Don't work on 8-bit values

The fact that base64 encoding has a 1-byte (or 1-ASCII-character) resolution the way it's defined does not mean that's how you need to decode it. Your machine is (probably) a 64-bit machine. So work on in 64-bits units unless you have reason to use another size (which you very well might - but probably not 8 bits). Work out the math for the larger sizes.

Now you might say "but what if the length of my output isn't divisible by 8?" - well, just handle the slack at the end, outside your main tight loop.

Similarly, you shouldn't use 4 distinct 8-bit variables for your input - use something bigger.

3. Don't mix decoding and allocation + don't force the use of std::vector

You should not be using an std::vector. Take a pointer to a nicely-aligned output buffer, or better yet - a gsl::span. (You could also take a templated iterator but I wouldn't bother) with sufficient memory pre-allocated, and write there.

If you insist on doing the allocation yourself for some reason, have a wrapper function do it. Right now you're allocating \$log(n)\$ times for decoding \$\frac{n}{6}\$ bits! C-R-A-Z-Y!.

At any rate, there's no reason to force the client code for your decoder to take an std::vector.

4. Are both lookup tables really helping you?

Using a look-up table means doing less computational work. But is the trade-off worth it? Not always. Now, if you be making your lookup table larger (which you may very well do, see the linked blog post and remember we want to work with more than 8 bits at a time) you might hit cache limits. And even if you aren't - maybe in-register arithmetic is good enough?

Now, I might be worrying you for nothing here, and maybe lookup tables are the best thing to do - but at least profile to make sure. In fact,

5. Profile profile profile

If @DJuracu wrote already - profile to find out what needs optimization. You can speed up something a zillion times, but if it's only 5% of the execution time you haven't saved much (Amdahl's law). Of course, after you've improved something else, those 5% may now become 50%, making it worthwhile to work on that part of the code after all. Still, you need to know what worked and what didn't.

6. You have to look at the compiled code

When you're writing code that's this low-level, you can't allow yourself the slack of ignoring the assembly. Learn to read it and do so. I know that's a tall order but you're the one who said you want to write something that's "fast"...

7. Multi-thread

If this is part of an application which already has multiple threads running, then forget this point. Otherwise - why use only one core, and with one thread on it? Assuming you're on a typical modern PC, you have 2 or 4 cores, and with 'HyperThreading', they can execute instructions from 4 or 8 threads overall. While you could theoretically be bottlenecked on memory bandwidth or some other resource at full 4 or 8 thread capacity, you might not. Especially if you're not well-enough SIMDized

8. Use SIMD for parallelism

Your processor supports vectorized instructions. Your decoding (and your decoding) does not have "dependency chains" between the values of consecutive characters, except at most when composing a larger word from fewer bits. So - you should be able to SIMDize all or almost all of this work. I'm a GPU guy more than a CPU guy, so I can't tell you which instructions you'll want to be using, but that would definitely be necessary for maximum speed. Probably best to work on this before going multi-threaded.

There's an inconsistency between to_base64 which maps integers to host characters and from_base64 which maps (char-sized) integers to integer values. The two transforms are consistent only when the host character coding represents the base-64 characters with the same code-points as in ASCII; not all character sets do so.

The correct portable way to fix this is to derive the decoder table from the encoder table.

Some optimizations scenarios just from looking at the code:

• Don't pass std::string encoded_string by value as you're making a useless copy. As you're only interested in an array of bytes, passing a string_view (or the traditional pointer + size) is more flexible.
• You know how big the resulting vectors will be, so using operator[] after increasing their size might be faster than constantly calling push_back().

For more opportunities for optimizations, profile the code to find bottlenecks.