我正在處理一個對對象進行大量操作的程序;創建，刪除，動態播放它們，對指針進行洗牌，比較內容等。這些對象中的大多數至少有40個字節（最多約90個字節），並且一次可能會有10,000個以上的內存。如何確定大型對象的性能成本（在C++中）
我想確定的是我是否應該打算減小它們的尺寸。我可以剖析構造函數，新建，刪除等。但是，我認爲大型對象最重要的性能來自緩存不友好。有沒有一種方式來確定對象大小對發生緩存未命中數量的貢獻？ PS：我想象過度使用dynamic_cast也會影響性能。但是這很容易診斷。
編輯：我知道沒有配置文件進行優化是沒有用的。我所要求的是如果從剖析中確定，如果它是一個問題，我該如何確定。懲罰是否可能在整個代碼中分佈，這樣標準分析工具將不會有所幫助？
你正以大多數人的方式接近它，直到它們穿過線並且得到它。正如Paul R在評論中所說，不要只是猜測。換句話說，你的整個方法應該圍繞診斷。 否則，你就像是一個醫生，他認爲每個人都是一樣的，並且對鵝有用的東西必須適用於這種鵝。
這是否意味着與緩存相關的問題不成問題？
這是否意味着內存分配問題不是問題？
不一定。
這意味着他們是猜測，他們可能是問題，但幾乎可以肯定有其他問題，沒有人可以提前猜測。
有討論here一個例子，其中六（6）被發現和固定不同的問題，具有一定範圍的，只是碰巧加起來幾乎所有的時候，順便一堆不同硬幣大小的大小可以加起來一美元。 當然，其中一個是內存分配，但只有一個。 如果你已經修復了內存分配問題並停在那裏，或者加上了一些其他的先入爲主的問題並停在那裏，你會得到多少加速？
實際顯示的加速比的一小部分。
要獲得真正的加速比就可以達到，你必須要找到每問題，而不只是少數。 該鏈接顯示如何做到這一點。
+1不錯的答案！ – 2012-07-08 20:23:30
@PaulR：謝謝。我永遠不知道該怎麼稱呼這些東西。我不喜歡「問題」，我真的不喜歡「瓶頸」，因爲這些詞在他們中有*怪*的味道，就像放入其中的一個是最好的錯誤。一些「問題」實際上是完美的代碼，沒有人會感到羞愧。恰恰相反，還有另一種方法可以做到這一點，從而減少了大部分時間。 – 2012-07-09 00:13:36
是的，我認爲把這種事情稱爲「優化機會」而不是「性能問題」可能更具有吸引力。 – 2012-07-09 05:57:30
您需要真正地分析代碼並查看瓶頸*的真實位置，而不是僅僅猜測。 – 2012-07-08 18:07:10
您可以嘗試valgrind中的cachegrind工具。 – 2012-07-08 18:09:48