使用QStrings作爲鍵的QHash查找的速度

Question

我需要在QImage上繪製動態覆蓋。疊加層的組成部分用XML定義，並解析爲一個QHash<QString, QPicture>，其中QString是名稱（例如「十字線」），而QPicture是獨立於分辨率的繪圖。然後，我會在運行時確定的位置繪製覆蓋圖的組件。

例如：我的QHash中有10張圖片，構成HUD中的每個可能元素。在特定的視頻幀中，我需要在圖像上的不同位置繪製6個視頻。在接下來的畫面中，有些東西已經改變了，現在我只需要畫出其中的4個，但其中2個已經改變了。

現在我的問題：如果我想盡快做到這一點，我應該重新定義我的QHash爲QHash<int, QPicture>並枚舉鍵來抵消由字符串比較造成的開銷;還是比較不會對性能產生很大影響？由於XML解析器和疊加作曲器是完全獨立的類，我可以輕鬆地轉換爲整型鍵;但我希望在整個應用程序中使用一致的數據結構。

爲了提高性能，我是否應該克服對一致性和可重用性的渴望？如果我做的事情會非常重要嗎？

Answer 1

Gareth當然有正確的答案。我想稍微擴展一下。

1. 爲了一致性和可重用性，首先進行了 。儘量不要引入巨大的 性能瓶頸;這是 難以達到平衡
2. 設置現實的性能標準。我猜你正在製作類似遊戲的遊戲，合理的標準是「在我的開發機器上維持25 fps」
3. 您的應用程序是否符合標準？是？足夠的優化，請轉至5.
4. 對您的應用程序進行配置文件，優化花費最多時間的部件。回到3.
5. 利潤！

回到你的具體問題，如果散列表中元素的數量少於或大約一百，那麼鍵類型可能根本就不重要。

Answer 2

答案是你應該分析你的應用程序。只有當你發現字符串比較是一個瓶頸時，你應該實施一個替代策略。不成熟的優化可能會浪費時間。

首先，確保程序的正確性，即確保它通過了所有的單元測試。 （我假設正確性和性能是正交的 - 除非您正在編寫硬實時應用程序，否則這通常是一個合理的假設）然後，找出性能是否符合您的要求的基準。只有在基準測試顯示性能太低時才應該優化，然後按照分析器的指導進行操作。您可以通過重新運行單元測試來檢查您所做的任何優化是否正確。