关于unique_ptr性能 [英] About unique_ptr performances

查看:377
本文介绍了关于unique_ptr性能的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述



我经常读到,在大多数情况下,unique_ptr将优先于shared_ptr,因为unique_ptr是不可复制的并且有移动语义; shared_ptr会由于复制和重新计数而增加开销;



但是当我在某些情况下测试unique_ptr时,它看起来比它的同行更慢/ p>

例如,在 gcc 4.5 下:



>:打印方法实际上不打印任何内容

  #include< iostream& 
#include< string>
#include< memory>
#include< chrono>
#include< vector>

类打印{

public:
void print(){}

};

void test()
{
typedef vector< shared_ptr< Print>> sh_vec;
typedef vector< unique_ptr< Print>> u_vec;

sh_vec shvec;
u_vec uvec;

//不能对unique_ptr使用initializer_list
for(int var = 0; var< 100; ++ var){

shared_ptr< Print> p(new Print());
shvec.push_back(p);

unique_ptr< Print> p1(new Print());
uvec.push_back(move(p1));

}

// ------------- test shared_ptr ---------------- ---------
auto time_sh_1 = std :: chrono :: system_clock :: now();

for(auto var = 0; var< 1000; ++ var)
{
for(auto it = shvec.begin(),end = shvec.end ); it!= end; ++ it)
{
(* it) - > print();
}
}

auto time_sh_2 = std :: chrono :: system_clock :: now();

cout<<test shared_ptr:< (time_sh_2-time_sh_1).count()< 微秒。 << endl;

// ------------- test unique_ptr -------------------------
auto time_u_1 = std :: chrono :: system_clock :: now();

for(auto var = 0; var< 1000; ++ var)
{
for(auto it = uvec.begin(),end = uvec.end ); it!= end; ++ it)
{
(* it) - > print();
}
}

auto time_u_2 = std :: chrono :: system_clock :: now();

cout<<test unique_ptr:< (time_u_2-time_u_1).count()< 微秒。 << endl;

}

平均我得到(g ++ -O0) p>


  • shared_ptr:1480微秒

  • unique_ptr:3350微秒



差异来自哪里?


解决方案

您在时间块中所做的一切都是访问它们。这不会涉及任何额外的开销。增加的时间可能来自控制台输出滚动。你永远不能,在一个定时的基准中做I / O。



如果你想测试ref计数的开销,然后实际做一些ref计数。如果永远不会改变<$ c $>,则 shared_ptr 的构建,销毁,分配和其他变更操作的时间增加c> shared_ptr



编辑:如果没有I / O,那么编译器优化在哪里?他们应该把整个事情搞砸了。即使是ideone junked很多。


I often read that unique_ptr would be preferred in most situations over shared_ptr because unique_ptr is non-copyable and has move semantics; shared_ptr would add an overhead due to copy and ref-counting;

But when I test unique_ptr in some situations, it appears it's noticably slower (in access) than its counterparts

For example, under gcc 4.5 :

edit : the print method doesn't print anything actually

#include <iostream>
#include <string>
#include <memory>
#include <chrono>
#include <vector>

class Print{

public:
void print(){}

};

void test()
{
 typedef vector<shared_ptr<Print>> sh_vec;
 typedef vector<unique_ptr<Print>> u_vec;

 sh_vec shvec;
 u_vec  uvec;

 //can't use initializer_list with unique_ptr
 for (int var = 0; var < 100; ++var) {

    shared_ptr<Print> p(new Print());
    shvec.push_back(p);

    unique_ptr<Print> p1(new Print());
    uvec.push_back(move(p1));

  }

 //-------------test shared_ptr-------------------------
 auto time_sh_1 = std::chrono::system_clock::now();

 for (auto var = 0; var < 1000; ++var) 
 {
   for(auto it = shvec.begin(), end = shvec.end(); it!= end; ++it)
   {
     (*it)->print();
   }
 }

 auto time_sh_2 = std::chrono::system_clock::now();

 cout <<"test shared_ptr : "<< (time_sh_2 - time_sh_1).count() << " microseconds." << endl;

 //-------------test unique_ptr-------------------------
 auto time_u_1 = std::chrono::system_clock::now();

 for (auto var = 0; var < 1000; ++var) 
 {
   for(auto it = uvec.begin(), end = uvec.end(); it!= end; ++it)
   {
     (*it)->print();
   }
 }

 auto time_u_2 = std::chrono::system_clock::now();

 cout <<"test unique_ptr : "<< (time_u_2 - time_u_1).count() << " microseconds." << endl;

}

On average I get (g++ -O0) :

  • shared_ptr : 1480 microseconds
  • unique_ptr : 3350 microseconds

where does the difference come from ? is it explainable ?

解决方案

All you did in the timed blocks is access them. That won't involve any additional overhead at all. The increased time probably comes from the console output scrolling. You can never, ever do I/O in a timed benchmark.

And if you want to test the overhead of ref counting, then actually do some ref counting. How is the increased time for construction, destruction, assignment and other mutating operations of shared_ptr going to factor in to your time at all if you never mutate shared_ptr?

Edit: If there's no I/O then where are the compiler optimizations? They should have nuked the whole thing. Even ideone junked the lot.

这篇关于关于unique_ptr性能的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆