性能圖C++找到（克++（GCC）4.4.7 20120313（紅帽4.4.7-3））

我有具有性能敏感的應用程序代碼等性能圖C++找到（克++（GCC）4.4.7 20120313（紅帽4.4.7-3））

for each record r 
    processRecord(r)

然後

processRecord(record r) 
{ 
    for each field in record r 
     processField (f) 
}

當我們的應用程序啓動時，它使用一個xml文件來填充地圖。讓我們稱它爲M.該地圖是字符串和結構。其中strung是xml標籤中的名稱，結構由xml中的所有其他元素組成。

processField中每個字段的處理是一個漫長的操作，我們需要上述地圖M的幫助來查找其在map中指定的屬性並相應地處理該字段。

我們有大量的數據來自外部，當我進行分析時，我發現最大時間花在了對地圖M進行查找操作上。

該地圖由xml中的字段組成，我可以放心地說地圖的大小在50-200之間。

發送到我們的應用程序的記錄數是每秒300個&每個記錄具有與地圖大小相同的比例。

網上的快速搜索表明，可以嘗試使用unordered_map，但它在我的舊C++編譯器中不可用，因爲我們沒有移動到C++ 11，這是我無法控制的東西。同樣在網絡上，對於像我的地圖和unordered_map這樣的小集合似乎會得到類似的結果。

如果地圖創建需要時間作爲一次性活動，但需要快速查找（），我們並不擔心。
所以，當我做了我的分析，我發現最大的時間花在做地圖M上的查找操作，我希望減少它。任何建議？

地圖的特定的API通過我的探查被refered我是（頂部2）

1) std::_Select1st<std::pair<int const, int> >::operator() (this=0x7f1a679eb1bf, __x=...) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_function.h:489 

and 

2) #0 0x00000000005e3d7f in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::~_Rb_tree (this=0x7f1a679ebf72, __in_chrg=<value optimized out>) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:613 
#1 0x00000000005e3d42 in std::set<int, std::less<int>, std::allocator<int> >::~set (this=0x7f1a679eb5d0, __in_chrg=<value optimized out>) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_set.h:88

編輯我是能夠改善PERF使用下面:)建議。我測試了一小組隨機數據。在std :: _ Rb_tree *中，我的CPU使用率爲std：map爲〜12.24％。使用boost :: unordered_map我只在boost :: unordered_detail :: *中獲得了4.34％所以這意味着我有~7％的CPU用於其他活動。

來源

2014-12-31 MAG

地圖持有什麼樣的數據，只是整數？ – BlamKiwi

2014年12月當前GCC爲4.9。您應該升級您的編譯器 –

如您所說，如果您不能升級，那麼升序無序地圖可能會有用。 http://www.boost.org/doc/libs/1_57_0/doc/html/unordered/comparison.html –

回答我自己的問題，因爲這個問題也可能發生在其他用戶身上。我能夠使用我的問題的評論部分中的建議來提高perf。

@RetiredNinja建議我使用boost無序地圖

要了解我提到link相同。來自該站點的相關文本是 有序地圖通常是基於有序樹實現的，例如STL的情況下爲紅黑樹。樹操作相對昂貴，但樹使用非常少的存儲空間。 無序映射通常實現爲散列表;較新的STL實現也提供這樣的地圖。散列表非常快，但是存在一些存儲開銷，並且在它們變得低效之前只能增長到一定數量的節點。

因爲我更困擾查找調用和插入將發生只有一次，我想嘗試一個無序的地圖boost :: unordered_map。空間限制對我來說並不重要，因爲我的地圖尺寸很小（最多200個元素）。

我測試了一小組隨機數據。我運行我的性能測試，找出哪些API現在正在消耗更多的CPU週期。在std :: _ Rb_tree *調用中，我使用std：map的cpu佔用率高達〜12.24％。使用boost :: unordered_map時，我在boost :: unordered_detail :: *調用中只添加了4.34％。所以這意味着我爲其他活動節省了大約7％的CPU。

如果其他人可以給我更多的方法，我仍然會等待，但現在這幫助了很多。

來源

2014-12-31 10:25:55 MAG

性能圖C++找到（克++（GCC）4.4.7 20120313（紅帽4.4.7-3））

回答

相關問題