Question

我有以下代码来测试复制ctor并移动std::string类的ctor，结果让我感到惊讶，移动ctor比复制ctor慢<〜> 1.4 倍。

据我所知，移动构造不需要分配内存，对于std::string情况，移动构造对象中可能有一个内部指针直接设置为移动对象的内部指针，它应该比为缓冲区分配内存更快，然后在复制构造时从对象复制内容。

以下是代码：

#include <string>
#include <iostream>

void CopyContruct(const std::string &s) {
  auto copy = std::string(s);
}

void MoveContruct(std::string &&s) {
  auto copy = std::move(s);
  //auto copy = std::string(std::move(s));
}

int main(int argc, const char *argv[]) {
  for (int i = 0; i < 50000000; ++i) {
    CopyContruct("hello world");
    //MoveContruct("hello world");
  }

  return 0;
}

修改

从两个函数的汇编中，我可以看到MoveConstruct std::remove_reference类模板的实例化，我认为这应该是罪魁祸首，但我不熟悉有了装配，有人可以详细说明吗？

以下代码在https://godbolt.org/上使用x86-64 gcc7.2：

进行反编译

CopyContruct(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&):
  push rbp
  mov rbp, rsp
  sub rsp, 48
  mov QWORD PTR [rbp-40], rdi
  mov rdx, QWORD PTR [rbp-40]
  lea rax, [rbp-32]
  mov rsi, rdx
  mov rdi, rax
  call std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
  lea rax, [rbp-32]
  mov rdi, rax
  call std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  nop
  leave
  ret
MoveContruct(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&):
  push rbp
  mov rbp, rsp
  sub rsp, 48
  mov QWORD PTR [rbp-40], rdi
  mov rax, QWORD PTR [rbp-40]
  mov rdi, rax
  call std::remove_reference<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&>::type&& std::move<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)
  mov rdx, rax
  lea rax, [rbp-32]
  mov rsi, rdx
  mov rdi, rax
  call std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&)
  lea rax, [rbp-32]
  mov rdi, rax
  call std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  nop
  leave
  ret

EDIT2：

观光＆＃39;变得有趣，我将std::string更改为std::vector为评论中提到的@FantasticMrFox，结果相反，MoveConstruct比~1.9快CopyConstruct倍，似乎std::remove_reference不是罪魁祸首，但这两个类的优化可能是。

EDIT3：

以下代码在MacOS上使用Apple LLVM 8.0.0版（clang-800.0.42.1）编译，优化标志为-O3。

    .section    __TEXT,__text,regular,pure_instructions
    .macosx_version_min 10, 11
    .globl  __Z12CopyContructRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE
    .align  4, 0x90
__Z12CopyContructRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE: ## @_Z12CopyContructRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE
    .cfi_startproc
## BB#0:
    pushq   %rbp
Ltmp0:
    .cfi_def_cfa_offset 16
Ltmp1:
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
Ltmp2:
    .cfi_def_cfa_register %rbp
    pushq   %rbx
    subq    $24, %rsp
Ltmp3:
    .cfi_offset %rbx, -24
    movq    %rdi, %rax
    leaq    -32(%rbp), %rbx
    movq    %rbx, %rdi
    movq    %rax, %rsi
    callq   __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC1ERKS5_
    movq    %rbx, %rdi
    callq   __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev
    addq    $24, %rsp
    popq    %rbx
    popq    %rbp
    retq
    .cfi_endproc

    .globl  __Z12MoveContructONSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE
    .align  4, 0x90
__Z12MoveContructONSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE: ## @_Z12MoveContructONSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE
    .cfi_startproc
## BB#0:
    pushq   %rbp
Ltmp4:
    .cfi_def_cfa_offset 16
Ltmp5:
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
Ltmp6:
    .cfi_def_cfa_register %rbp
    subq    $32, %rsp
    movq    16(%rdi), %rax
    movq    %rax, -8(%rbp)
    movq    (%rdi), %rax
    movq    8(%rdi), %rcx
    movq    %rcx, -16(%rbp)
    movq    %rax, -24(%rbp)
    movq    $0, 16(%rdi)
    movq    $0, 8(%rdi)
    movq    $0, (%rdi)
    leaq    -24(%rbp), %rdi
    callq   __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev
    addq    $32, %rsp
    popq    %rbp
    retq
    .cfi_endproc

Answer 1

这种微基准测试通常会产生误导，因为它没有测试你认为测试的东西。

但是，在您的情况下，我可以解释您最常见的测量原因。

在所有现代实现中，

std::string使用称为＆＃34;小缓冲区优化＆＃34;或SBO的东西。（@ FantasticMrFox在关于使用flyweight的评论中的断言是错误的。我不认为任何流行的实现曾经使用flyweight除了空字符串。他的意思是写拷贝，GNU使用＃ 39;过去的标准库，但由于兼容的C ++ 11字符串不能使用COW，因此GNU被移除了。）

在此优化中，字符串对象内部保留了一些空间来存储短字符串并避免为它们分配堆。

这意味着字符串的复制和移动构造函数大致如下所示：

copy(source) {
  if source length > internal buffer capacity
    allocate space
  copy source buffer to my buffer
}

move(source) {
  if source uses internal buffer {
    copy source buffer to my buffer
    set source length to zero
    set first byte of source buffer to zero
  } else {
    steal source buffer
  }
}

如您所见，移动构造函数有点复杂。它在某些实现中也比一些实现更优化，但一般逻辑保持不变。

因此对于小缓冲区字符串（我怀疑你正在测试的那个适合你的特定实现），复制的工作要少，因为源字符串不是需要重置。

但是当你打开完全优化时，编译器可能会识别一些死存储并删除它们。（当然，编译器可能会删除整个基准测试，因为它实际上并没有做任何事情。）

Answer 2

当我从clang那里得到I feed your code to clang or gcc with -O3时：

main: # @main
  mov eax, 50000000
.LBB0_1: # =>This Inner Loop Header: Depth=1
  add eax, -25
  jne .LBB0_1
  xor eax, eax
  ret

和gcc：

main:
  xor eax, eax
  ret

我确实将函数放在匿名命名空间中，以消除必须导出函数本身的噪音。但主要是完全优化了。

微量标记经常会产生误导。

为什么移动ctor比复制ctor慢？

2 个答案: