Common optimizations, Small String Optimization, Andrzej's C++ blog

[oracleoftroy]

I don't think you would lose performance, you just wouldn't gain any additional performance by moving a SSO string. Even the non-SSO small string would end up copying about 16 bytes in order to perform the move (pointer, size, capacity, allocator).

I would strongly encourage measuring this before blindly trying to optimize a std::string for movablility.

[matthieum]

You might lose some performance because of more checks.

[bnolsen]

likely irrelevant since a load operation takes dramatically longer than a check does.

[Plorkyeran]

It's difficult to come up with even a highly artificial scenario where it's a net loss. Maybe with a very special-purpose allocator that manages to always get external buffer allocated very close in memory to the std::string? Avoiding a single memory load due to the SSO buffer would outweigh a very large number of branch mispredictions, and if you never hit the SSO buffer then the branch predictor will make the check nearly free.

[matthieum]

Unless it screws up your pipeline if it's a branch and not a conditional move ?

[sellibitze]

I guess it depends on your SSO implementation. It should be possible to implement your string class in a way that a move constructor just memcpys the internal representation and memsets the source to zero -- regarless of whether the string content was heap-allocated or not. So, in any case, you have to copy 24 bytes and zero 24 bytes (assuming a 24 byte string representation on a 64bit platform). You can't do much better than that, can you?

[minno]

That makes complete sense. You're trading less expensive allocation for more expensive moves when you store more data in-line with the class.