2013-03-11 67 views
0

我在Ubuntu上,我正在研究计算机视觉应用程序(光学流程),并且正在使用valgrind对代码进行分析。 分析后,我发现shared_ptr占据了应用程序的74%。请在附件中找到使用shared_ptr的代码。我正在寻找一个优化。除此之外,sprintf也花费了很多时间,而openMP线程也吃了很多。我真的想知道sprinft,和OpenMP成本...Shared_Ptr我的应用程序的性能

int main(int argc, char *argv[]) 
{ 
    //QApplication a(argc, argv); 


    omp_set_dynamic(0); 
    omp_set_num_threads(4); 

    double t1, t2; 

    // ------------- Initialization: Frames. -------------- 

    // Load first image 
    char imFName[1024]; 
    sprintf(imFName, "%s/img_%08i.png", imPath.c_str(), imIndex); 
    ifstream fileExists(imFName); 

    if (!fileExists) 
    { 
     printf("First image %s/img_%08i.png could not be loaded!", imPath.c_str(), imIndex); 
     return -1; 
    } 

    QImagePtr prevImg; 
    QImagePtr curImg(new QImage(QString(imFName))); 



} 
+0

这并不足以让我们做任何事情。 “ZtAbsoluteSystemItem”是做什么的? – 2013-03-11 10:25:31

+1

要了解shared_ptr是否是问题,请将分析结果与本机指针和unique_ptr进行比较。 – 2013-03-11 10:27:34

+0

@TonyTheLion只是初始化摄像头参数。 – Andre 2013-03-11 10:28:57

回答

3

我怀疑shared_ptr是罪魁祸首,但newdelete

您在堆上分配内存,将其分配给item,并且for循环的作用域结束时释放它。所以你有一个昂贵的noop。

作为@nvoigt已经建议,使用自动对象

CharachterDetection item(frame); 

和更改存取从item->item.

在你的图片中,位置是/usr/arm-linux-gnueabihf/...。如果这不是本地运行,而是在模拟虚拟机上,我不会依赖任何结果。

更新

您运行在一个循环sprintf和反复拷贝的路径,之后把它放在一个QString的一次。也许使用QString::arg之一更适合。但这只是一个猜测。

+0

所以我应该怎么做才能解决这个问题?只是分配在堆栈上? – Andre 2013-03-11 10:35:50

+0

@Mahmoud是的,如果你的对象不是太大,这将是正确的修复。 – 2013-03-11 10:38:46

+0

你也有一个想法,为什么sprintf需要很多时间? – Andre 2013-03-11 10:40:59

2

也许你在你的文章中缺少一些代码?你的共享指针似乎没有做任何事情,只是构建和删除你的对象。如果需要说对象的构造函数的代码,你可以只是把对象在栈上:

// ----------------------- Perform Marker Detection ------------------------ 
ZtAbsoluteSystemItem item(frame); 
+0

我发布了完整的代码和分析器图像 – Andre 2013-03-11 10:36:06

+0

我还不清楚你为什么使用shared_ptr而不是将对象放在堆栈上。它对于堆栈来说太大了吗,还是我错过了将代码插入跨循环生命周期的某个容器的代码的一部分? – nvoigt 2013-03-11 10:49:34

0

很难从你的代码究竟在何处的问题,就是要告诉,所以我只能提供建议的两种通用件我发现过去很有用:

  • 避免手动使用new,查看std::make_shared以使分配更有效。
  • 避免无用的参考计数。当参数为std::shared_ptr时,请将其作为const std::shared_ptr<...>&,而不是创建std::shared_ptr的副本,这意味着每个函数调用的原子增量和减量。