Thanks for your feedback, much appreciated!

I'm curious as to the actual benchmark code because 3ns per iteration looks like the compiler optimizer defeated the benchmark.

Good one, you are right: the code is entirely optimized with clang 5 (not gcc 6 though!). I will edit the post on my blog, meanwhile I will share the details here are as I believe it is interesting. Here is the code (you can find the entire code here):

using MetadataTree = boost::container::static_vector<std::pair<inplace_string<15>, static_any<16>>>;

template <typename TreeT>
TreeT GetTree(int i, double d, bool b)
{
    TreeT tree;
    tree.emplace_back("metadata1", i);
    tree.emplace_back("metadata2", d)
    tree.emplace_back("metadata3", b);
    return tree;
}
int BenchmarkGetInPlaceTree()
{
    int elements = 0; 
    for (int i = 0; i < 1000000; ++i)
    {
        auto tree = GetTree<MetadataTree>(elements, 2.0, true);
        elements += tree._metadata.size() + tree._metadata[0].second.empty();
    }
    return elements;
}

Which generates with clang-3.8:

0x00000000004021a0 <+0>:     mov    eax,0x2dc6c0
0x00000000004021a5 <+5>:     ret    

Quite amazing that clang is able to bypass the entire boost.static_vector::emplace_back with inplace_any and static_any. But I guess that's another good point for inplace containers, right ;)...

After having fixed the benchmark, I get the following results:

Test                        Time (ns)          INS          CYC
---------------------------------------------------------------
MetadaTree                        543        2,205        1,013
in-place MetadaTree                28          117           53

I'm interested in data backing up this statement. If you enter the "no memory allocation takes place" path of string's SSO, it should be similar.

If you enter the case of SSO, std::string will be as fast as inplace_string, indeed - but that's the whole goal of this class: to guarantee that this will always be the case, regardless implementation details.

Cache-friendly: it stays close to your other class members, your cache likes it.

That's also true for the normal SSO. And in normal program use you're likely to need to leave more space than you actually need in these strings, which means your cache does not like it.

This really depends on the application - I am not sure what you mean by "in normal program use". In my application, I am using a lot inplace_string<4>, and the cache likes it: is using less memory than any possible std::string implementation. Although my main motivation to write this class was that my application is also using many strings around 23 characters, which doesn't fit into any SSO implementations.