We're shown this :
Wow! Move enabled is great !
Oh wait. He's testing std::sort on vector< set< int > > , which is pretty contrived and one of the classic "don't do" examples, but whatever, that's fine. Oh, and he's intentionally broken RVO (return value optimization) , which is pretty crucial to making the STL run fast.
Like hay, if you construct a synthetic example that does lots of copies without move and doesn't do them with move, it's faster!
Yeah, move is great, I'm all for it, but let's be clear what it's doing : it's making it easier to write code, and it's letting you use certain patterns that were previously verboten. It is *not* speeding up real world performant code. Existing real world high performance code *already* never copies large objects. You currently get around that by making heavy use of RVO , of swap() to avoid copies, and by using pointers to objects instead of objects by value. What move gives us is the ability to write fast code without worrying about those things.
The penalty of move (and rvalues in general) is yet more intellectual burden, something you have to be careful about and understand and implement in your new data types correctly, and yet another thing for people to do wrong.