2013-01-09 76 views
0

我有一種情況,我需要從潛在的大std::string(我用20M std::string進行壓力測試)中解析很多小std::string。我跟蹤我想解析的std::string開頭的索引,當我到達std::string的末尾時,我做一個大的substr。然後我使用這些std::string s作爲std::map的密鑰解析出來。C++字符串實例化與strncpy/memcopy

我期望通過切換到char*使其更快運行。我需要做的是維護指向我想要解析的字符串的開頭的指針,在解析字符串時計算字符串的長度,然後實例化一個新的char*,它保存解析出的字符串的長度。然後我將strncpy/memcpy的字符串放入新的char*。當我使用這個新的char*作爲std::map的關鍵時,我必須提供一個運行strcmp的比較仿函數。

現在我已經有了東西,總共需要290毫秒的總計來解析字符串,而不用插入std::map(插入時總共需要450毫秒)。將切換到char*顯着(任何50毫秒+)更好的結果?

+0

沒有人能夠明確地回答這個問題。運行代碼並對其進行基準測試。 – Jon

+0

不,你不應該改用'char *'。改寫一個新的優化類。 – Pubby

+1

找出最好的方法是實現這兩個版本並對它們進行配置。 –

回答

3

首先,沒有人不知道真正的答案,所以你不妨嘗試一下。但其次,我們可以做出有根據的猜測:可能不是;無論如何,這全是std::string

你應該做的是創建一個表示現有字符串範圍內的類(即存儲一對迭代器),並將此類用作映射的索引。通過這種方式,您可以避免分配一堆小字符串,這至少在加載過程中幾乎可以確定您的大部分性能來自哪裏。然後你只需將源字符串保存在內存中,這樣迭代器仍然有效。

如果您主要執行查找(您可以緩存哈希結果,因爲您現在正在處理不可變字符串),您也可以考慮使用unordered_map,但是再次瞭解這種情況是否會更快的唯一方法是相同的方法適用於所有性能問題:測試和數據

+2

你不需要使類GManNickG描述,它已經存在於升壓範圍。 'boost :: iterator_range ' –

+2

...如果您在地圖中使用'boost :: iterator_range '作爲鍵,您可能需要定義一個詞法'bool運算符<(boost :: iterator_range const&,boost :: iterator_range const&)'。 –

+0

@JamesBrock:很高興知道。 :) – GManNickG