C++ 使用qString作为键的QHash查找速度

我需要在

QImage

上绘制一个动态覆盖图。覆盖的组成部分用XML定义，并解析为

QHash

，其中QString是名称（如“十字光标”），而

QPicture

是分辨率独立的图形。然后，我在运行时确定的位置绘制所需的覆盖组件

示例：我的QHash中有10张图片，构成HUD中的每个可能元素。在视频的一个特定帧中，我需要在图像的不同位置绘制其中的6个。在下一帧中，有些东西发生了变化，现在我只需要画其中4个，但其中2个位置发生了变化

现在我的问题是：如果我想快速完成这项工作，我是否应该将我的QHash重新定义为

QHash

，并枚举键以抵消字符串比较造成的开销；还是这些比较不会对绩效产生很大影响？我可以很容易地转换为整数键，因为XML解析器和overlay composer是完全独立的类；但我希望在整个应用程序中使用一致的数据结构

---

为了提高性能，我是否应该克服对一致性和可重用性的渴望？如果我这样做，这会有很大影响吗？

答案是你应该对你的应用程序进行评测。只有当您发现字符串比较是一个瓶颈时，才应该实施替代策略。过早优化可能是浪费时间

---

首先，确保程序的正确性，即确保它通过了所有的单元测试。（我假设正确性和性能是正交的——这通常是一个合理的假设，除非您正在编写硬实时应用程序）然后，通过基准测试来确定性能是否满足您的要求。只有当基准测试显示性能太低时，您才应该进行优化，然后按照分析器的指导进行优化。您所做的任何优化都可以通过重新运行单元测试来检查其正确性。

Gareth当然有正确的答案。我想把它延长一点

追求一致性和可重用性 第一。尽量不要引入巨大的 性能瓶颈；它是 难以平衡

设定现实的绩效标准。我猜你在做游戏，一个合理的标准是“在我的开发机器上保持25 fps”

你的申请符合标准吗？对足够的优化，请转到5

配置应用程序，优化耗时最多的部分。回到3

利润

---

回到您的具体问题，如果哈希表中的元素数小于或大约为100，则键类型可能根本不重要

谢谢sbk#我的整个设计理念只用了两句话。我正朝这个方向倾斜，但需要一点推动。另外，我和很多“所有的字符串比较都是邪恶的”思想流派的人一起工作，我觉得我应该得到外界的意见。是的，我的主要具体要求是保持每秒30帧+1为了阐明基准测试应该先于优化，感谢gareth的快速回答，但我不得不接受sbk的答案，因为它背后的原因。我只是对没有详细解释的硬性规定有点警惕。无论如何，投票吧，因为总的来说我同意你的观点。