Question

我在这里问我的看法是否真实。我原本以为定义vector<T> v(size_t someSize, T init_value)会调用vector<T>::reserve之类的函数，而不是vector<T>::push_back。我在这里找到了一些与此有关的讨论：std::vector push_back is bottleneck，但这个想法略有不同。

运行一些实验，我注意到vector<T> v(size_t someSize, T init_value)一直调用::push_back。这是真的？我使用uftrace（https://github.com/namhyung/uftrace）进行了以下报告。

     Avg total   Min total   Max total  Function
==========  ==========  ==========  ====================================
858.323 ms  858.323 ms  858.323 ms  main
618.245 ms  618.245 ms  618.245 ms  sortKaway
234.795 ms  234.795 ms  234.795 ms  std::sort
 72.752 us   72.752 us   72.752 us  std::vector::_M_fill_initialize
 65.788 us   49.551 us   82.026 us  std::vector::vector
 20.292 us   11.387 us   68.629 us  std::vector::_M_emplace_back_aux
 18.722 us   17.263 us   20.181 us  std::equal
 18.472 us   18.472 us   18.472 us  std::vector::~vector
 17.891 us   10.002 us  102.079 us  std::vector::push_back // push_back?!

vector<T>::reserve最终是否也会呼叫vector<t>::push_back？ vector是否有更快的版本？

以上是原帖。经过一些评论，我测试了一个简单版本，并意识到我完全错了。

#include <vector>
#include <functional>
#include <queue>
#include <cassert>
using namespace std; // for the time being

int main () {
    vector<int> v(10, 0);

    return 0;
}

这实际上会产生以下结果，但不涉及std::vector<T>::push_back。

  # Function Call Graph for 'main' (session: 9ce7f6bb33885ff7)
  =============== BACKTRACE ===============
   backtrace #0: hit 1, time  12.710 us
     [0] main (0x4009c6)

  ========== FUNCTION CALL GRAPH ==========
    12.710 us : (1) main
     0.591 us :  +-(1) std::allocator::allocator
     0.096 us :  | (1) __gnu_cxx::new_allocator::new_allocator
              :  | 
     6.880 us :  +-(1) std::vector::vector
     4.338 us :  |  +-(1) std::_Vector_base::_Vector_base
     0.680 us :  |  |  +-(1) std::_Vector_base::_Vector_impl::_Vector_impl
     0.445 us :  |  |  | (1) std::allocator::allocator
     0.095 us :  |  |  | (1) __gnu_cxx::new_allocator::new_allocator
              :  |  |  | 
     3.294 us :  |  |  +-(1) std::_Vector_base::_M_create_storage
     3.073 us :  |  |    (1) std::_Vector_base::_M_allocate
     2.849 us :  |  |    (1) std::allocator_traits::allocate
     2.623 us :  |  |    (1) __gnu_cxx::new_allocator::allocate
     0.095 us :  |  |     +-(1) __gnu_cxx::new_allocator::max_size
              :  |  |     | 
     1.867 us :  |  |     +-(1) operator new
              :  |  | 
     2.183 us :  |  +-(1) std::vector::_M_fill_initialize
     0.095 us :  |     +-(1) std::_Vector_base::_M_get_Tp_allocator
              :  |     | 
     1.660 us :  |     +-(1) std::__uninitialized_fill_n_a
     1.441 us :  |       (1) std::uninitialized_fill_n
     1.215 us :  |       (1) std::__uninitialized_fill_n::__uninit_fill_n
     0.988 us :  |       (1) std::fill_n
     0.445 us :  |        +-(1) std::__niter_base
     0.096 us :  |        | (1) std::_Iter_base::_S_base
              :  |        | 
     0.133 us :  |        +-(1) std::__fill_n_a

很抱歉这个混乱。是的，库实现按预期工作，如果使用push_back构建，则不涉及initial size。

Answer 1

P，看起来你回答了自己的问题！我有点困惑了一会儿。假设，我可以想象使用vector's和reserve的{{1}}填充构造函数的一些模糊情况，但绝对不是像GNU中伴随GCC那样的高质量实现标准库。我假设，假设有一种模糊的矢量实现可能以这种方式实现，但实际上完全不可能实现任何体面的实现。

恰恰相反，这是差不多20年前的事了，但我试图实现我的push_backs版本以期与其性能相匹配。这不仅仅是一些愚蠢的练习，但诱惑是因为我们有一个软件开发工具包并且想要使用一些基本的C ++容器，但它的目标是允许人们为我们的软件编写插件使用不同的编译器（以及不同的标准库实现）比我们使用的。因此，我们无法在这些上下文中安全地使用std::vector，因为我们的版本可能与插件编写者不匹配。我们被迫不情愿地为SDK推出自己的容器。

相反，我发现std::vector在难以匹配的方式上非常有效，特别是对于具有琐碎的ctors和dtors的普通旧数据类型。这是十多年前的事情，但我发现在MSVC 5或6中使用填充构造函数std::vector（忘记哪一个）实际上转换为与使用vector<int>相同的反汇编，这与我的天真版本相同，只是循环遍历事物并使用新的放置，无论它们是否是POD，都没有。范围ctor也有效地转换为POD的超快memset。这正是使得矢量如此难以为我击败的原因，至少在那时候。在没有深入了解类型特征和特殊套管POD的情况下，我无法真正匹配POD的矢量性能。我可以将它与UDT匹配，但我们的大多数性能关键代码都倾向于使用POD。

因此，当我进行这些测试时，今天流行的矢量实现可能同样有效，并且我希望能够保证你的矢量实现很可能是快速的。我希望它做的最后一件事是使用memcpy实现填充或范围ctors。

vector <t> :: push_back用于预定义的构造函数？

1 个答案: