2008-09-23 24 views
3

我正在研究大規模使用STL的計算庫。該庫正在使用MSVC2003構建,並且正在使用其STL實現。 我正在尋找一種替代的STL實現,它可以幫助庫降低其內存要求並提高其性能。什麼是最低內存佔用的STL實現?

目前無法切換到較新版本的MSVC。

如果可能的話,我想關於真實世界使用情況的一些反饋,而不是基於基準。

編輯:使它更清晰一些,例如一些STL實現(如STLSoft)提出了字符串連接的特定優化;這些影響可能聽起來很小,但它們可能導致很大的改進。 STLPort是另一個很好的例子,他們清楚地闡述了他們的目標:有最快速的STL實現,stdlib ++等......所有這些都可以成爲很好的候選人,但我沒有時間去測試它們,我需要一些社區幫助在那。

+0

如果您將問題更改爲「什麼是......最低內存消耗」,或將主觀標籤添加到它,那麼可能會更好。 – 2008-09-23 16:42:29

+0

感謝您的建議...... – 2008-09-23 21:35:45

+0

我想知道LLVM項目中的新libC++如何與其他實現進行比較。據說它依靠一些C++ 11功能來獲得更好的性能。任何人都有使用經驗? – 2011-12-04 15:27:33

回答

4

STLPort。沒有測量內存使用差異,但它肯定更快(是的,真實世界的使用)。

+1

即使視頻遊戲開發人員使用STLPort也很有用。參見:文物。 – jkeys 2009-08-06 17:04:59

3

我質疑你的基本前提,你不能切換到MSVC的更新版本。

我不認爲你會通過下載一個新的STL來「免費」獲得更低的內存和更高的性能。或者至少,如果你這樣做了,你可能需要做很多代碼修復,就像你只是更新到最新的MSVC一樣。

長期來看,你不需要更新...現在就做,而你可能會很幸運,並獲得一些免費的內存和性能。我可以考慮向你建議的唯一方法就是根據你所尋找的內容向你提供建議,那就是嘗試使用英特爾編譯器,我已經使用了英特爾編譯器(性能!)和壞的(古怪的,有時候!)經驗。

除此之外,找到自己的內存和性能問題,並編寫自定義容器和算法。 STL很棒,但它並不是解決所有問題的萬能解決方案。領域知識是你最好的盟友。

0

大多數STL實現,包括MSVC2003中的一個,都是很好實現的通用庫。所以你不會看到從一個實現到另一個的顯着性能提升。

但是,有時您可以爲STL編寫比STL更快的算法(或容器),因爲您知道STL編寫器沒有新增的數據(因爲他們正在編寫通用容器和算法)。總之,如果你想提高你的應用程序的性能,你最好試着創建適合你的數據的專用容器,而不是尋找更高性能的STL。

0

如果性能對您的應用程序至關重要,並且STL交織在一起,是否有可能找到一個開源實現(如前面提到的STL-Port)並自行分發,從而根據需要改進性能?

一方面,我可以看到這成爲一個滑坡,你對STL庫的fork進行非標準修改,從而產生問題。但是,應用程序性能的重要性可能會超過發生這種情況的風險。

2

你有沒有考慮編寫自己的內存分配器?如果你不喜歡內存分配策略,你並不總是需要切換整個STL。所有容器都接受替換分配器。

1

你有異形你的代碼,並認爲小調整到那些有問題的地方?我會認爲這比你所考慮的要少得多。

1

大部分取決於您正在談論哪個容器以及您如何使用它。 矢量通常佔用的空間最小,除了在添加超出當前矢量容量的元素時。在那一刻,它會分配1.5倍的當前向量容量,移動元素(或者在最壞的情況下創建一個新的副本,它也分配內存),當這樣做完成時,刪除舊的向量內部構件,如果你知道如何許多元素,它會保留在前面,使用儲備矢量是你最好的選擇。

第二小的是列表。它的優點是它不會自行製作臨時副本。在那之後,你最好的選擇就是設定。有些實現現在已經很少了,在這些情況下,使用分配器可以很容易地將內存打包在頁面中。 遠離內存豬一樣unordered_ *

在MSVC客場一定要#定義_SECURE_SCL = 0這需要了大量的開銷用於安全編程的檢查(如緩衝區溢出等)

到最遠內存高效的容器是提升/侵入性這些有很小的腳印,因爲它們使用被包含的東西的內存。因此,爲鏈接列表或rb樹節點的一小塊內存進行堆棧化,節點指針是對象本身的一部分。然後「容器」只是構成根節點的幾個指針的一個原始集合。我已經使用了很多次來擺脫足跡和分配開銷。

相關問題