C++加速方法調用

我正在處理一個非常耗時的應用程序，我想加快一點。我使用ctime庫的clock（）函數分析了單個部件的運行時間，發現了一些東西，這對我來說並不完全清楚。C++加速方法調用

我有時間打印方法的外部和內部，我們稱之爲Method1。 Method1內部的打印包括它的整個主體，當然只有浮動的返回被排除。那麼，事情是，外面的打印狀態是Method1內部打印時間的兩倍到三倍。很明顯，外面的印刷品應該陳述更多的時間，但差異對我來說似乎相當大。

我的方法如下所示，我使用引用和指針作爲參數來防止數據複製。請注意，數據向量包含330.000個指向實例的指針。

float ClassA::Method1(vector<DataClass*>& data, TreeClass* node) 
{ 
    //start time measurement 
    vector<Mat> offset_vec_1 = vector<Mat>(); 
    vector<Mat> offset_vec_2 = vector<Mat>(); 
    for (int i = 0; i < data.size(); i++) 
    { 
     DataClass* cur_data = data.at(i); 
     Mat offset1 = Mat(); 
     Mat offset2 = Mat(); 

     getChildParentOffsets(cur_data, node, offset1, offset2); 

     offset_vec_1.push_back(offset1); 
     offset_vec_2.push_back(offset2); 
    } 

    float ret = CalculateCovarReturnTrace(offset_vec_1) + CalculateCovarReturnTrace(offset_vec_2); 
    //end time measurement 
    return ret; 
}

是否有任何「明顯」的方式來提高通話速度？爲了可讀性的原因，我寧願保留該方法，因此，我可以改變任何事情以加快速度？

我很欣賞任何建議！

來源

2016-03-28 Icarus

除非您找到內聯您的功能的方法，否則增加呼叫速度的可能性不大。 –

一個顯而易見的方法是設置編譯器的優化標誌。但是您應該詳細描述該方法的功能，方法簽名不會給我們任何提示。 –

可能有析構函數調用佔用時間...如果在函數內部創建了很多複雜的結構，可能會有很多要清理的東西 – vu1p3n0x

根據您更新的代碼，函數調用後結束時間測量和測量之間唯一的代碼是函數中構造對象的析構函數。這是每個330,000個Mat的兩個向量。根據這些Mat中的每一個所使用的資源，這可能需要一些時間。

來源

2016-03-28 14:46:52 vu1p3n0x

這樣的東西可能會發生的一個普遍問題是，你可能很快就有這些動態對象的數千份副本放在堆中，等待垃圾收集...而且，現在不僅垃圾收集相當昂貴，當它確實到來時，但整個堆區很大。（Ergo，很可能導致大量的頁面錯誤）。如果對這個Mat對象進行「擦除」操作，將被移除的元素放入某種自由列表中以便回收，這可能會有所幫助。但是，如果它只是「自由（）」的一切，那不會。 VM分頁是殺死時鐘的時間。 –

墊子很小，只有3個浮子。因此，他們應該需要少於8 MB。 – Icarus

嗯，只是好奇這些OpenCV的'地墊'或其他一些結構？我真正要問的是類似邁克羅賓森所說的。因爲如果它們是單獨的分配，那需要一些時間來釋放，但如果它們不是，因此通過「std :: vector」進行連續分配的一部分，那麼我預計它會很快 – vu1p3n0x

沒有試圖宣稱對任何其他人所做的任擇議定書的評論...

（1）短的答案很可能是，「不」。這個功能看起來很清楚，它做了大量的工作30,000次。然後，它正在對「所有數據」進行計算。（2）考慮重複使用「偏移1」和「偏移2」矩陣，而不是爲每次迭代創建全新的矩陣。當然，這是否真的會更快呢還有待觀察。（在任何情況下，見下文，它相當於「diddling的代碼。」）

（3）因此，從借款編程風格的要素：「不要‘騙取’的代碼，使它更快：找到更好的算法。「在這種情況下，可能沒有一個。您可能需要通過「向其投擲硅片」來解決運行時問題，並且我建議首先要做的是將盡可能多的RAM添加到此計算機上。「處理大量數據」的過程非常容易受到虛擬內存頁面錯誤的影響，每個虛擬內存頁面錯誤需要數毫秒的時間才能解決。（第二附加了那些真正的百分之快。）

我個人沒有看到任何斷然不對的代碼，也沒有任何會斷然導致它運行得更快。我也不會主張重寫（「diddling」）這個代碼來自你現在擁有的非常清晰的表達。

來源

2016-03-28 14:39:02

我upvoted。但我確實想要指出，你並沒有真正解決這個問題。您對如何優化方法提出了建議，但是您沒有提供關於爲什麼內部測量顯示的值比外部測量值小得多的解釋。（可能是因爲矩陣釋放，正如vu1p3n0x指出的那樣。） – JSQuareD

事實上，我沒有解決這個問題，因爲我所能提供的任何意見都只是一個受過教育的猜測......一種與您的猜測非常相似的猜測。 –

謝謝。我會在（2）中嘗試你的建議。關於（3）你是對的。不過，我知道肯定，內存不會用完（我已經優化了）。 – Icarus

C++加速方法調用

回答

相關問題