Try cppcodec with MSVC __forceinline

[jpetso]

As the author of cppcodec, I'd like to say thanks for putting this out! The main objective for my library was to provide a decent API with workable performance, so it's good to know that it doesn't fail entirely on that front. However, according to your graphs it could be better.

I only had the opportunity to time it on gcc and clang, both Linux. Since you're running your tests on MSVC, I was hoping you could try something out for me.

I found that after a refactor, cppcodec performance was noticeably slower than before. I traced this down to GCC not inlining some of the lowest-level templated functions (cppcodec is a template-crazy beast), and adding __attribute((always_inline)) made it go back to its original, okay performance. (That attribute also works on clang.)

I wonder whether the same thing is happening with MSVC. However, lacking a Windows system, I can't test it. So here's my request: Would you be able to add another line for MSVC's __forceinline to https://github.com/tplgy/cppcodec/blob/master/cppcodec/detail/config.hpp and see it that makes a difference in performance?

If I'm doing it right, I think it should look like this:

#if __GNUC__ || __has_attribute(always_inline)
#define CPPCODEC_ALWAYS_INLINE inline __attribute__((always_inline))
#if defined(_MSC_VER) && !__INTEL_COMPILER && _MSC_VER >= 1310 // since Visual Studio .NET 2003
#define CPPCODEC_ALWAYS_INLINE inline __forceinline
#else
#define CPPCODEC_ALWAYS_INLINE inline
#endif

If you don't have the time then that's okay. Thanks anyway!

[jpetso]

So I got around to doing this myself, and the snippet worked although it was only a minor part of the cppcodec performance lag. I worked on further improvements and got times down to about 100 microseconds on encoding and decoding for MSVC, Win32 (a.k.a. x86) as well as x64 builds. See the following table for measurements of the originally benchmarked cppcodec (commit 61d9b04) and my current working draft:

https://gist.github.com/jpetso/49d07bb87b3c6235d3d493a9e088c081

Also handy to compare performance of Win32 and x86 builds of the other implementations. Note that I left out libb64 because it wouldn't fetch correctly, see issue #3.

[gaspardpetit]

Thanks! I will get around to updating this branch eventually - for now I am counting the free minutes I have between an infinite backlog at work and a baby who believes that sleep is overrated :)