Speed of QHash lookups using QStrings as keys

Question

I need to draw a dynamic overlay on a QImage. The component parts of the overlay are defined in XML and parsed out to a QHash<QString, QPicture> where the QString is the name (such as "crosshairs") and the QPicture is the resolution independent drawing. I then draw components of the overlay as they are needed at a position determined during runtime.

Example: I have 10 pictures in my QHash composing every possible element in a HUD. During a particular frame of video I need to draw 6 of them at different positions on the image. During the next frame something has changed and now I only need to draw 4 of them but 2 of those positions have changed.

Now to my question: If I am trying to do this quickly, should I redefine my QHash as QHash<int, QPicture> and enumerate the keys to counteract the overhead caused by string comparisons; or are the comparisons not going to make a very big impact on performance? I can easily make the conversion to integer keys as the XML parser and overlay composer are completely separate classes; but I would like to use a consistent data structure across the application.

Should I overcome my desire for consistency and re-usability in order to increase performance? Will it even matter very much if I do?

Answer 1

Gareth has the right answer of course. I'd like to extend it a tiny bit.

1. Go for consistency and reusability first. Try not introduce huge performance bottlenecks too; it's hard to strike the balance
2. Set realistic performance criteria. I'm guessing you are making something game-like, a reasonable criteria would be "sustaining 25 fps on my dev machine"
3. Is your application meeting the criteria? Yes? Enough optimizations, go to 5.
4. Profile your application, optimize the parts that take the most time. Go back to 3.
5. Profit!

Back to your concrete question, if the number of elements in your hash table is less than or about a hundred, the key type probably won't matter at all.

Answer 2

The answer is that you should profile your app. Only if you find string comparisons to be a bottleneck should you implement an alternative strategy. Premature optimisation is likely to be a waste of time.

First, ensure the correctness of your program, i.e. make sure it passes all of its unit tests. (I'm assuming that correctness and performance are orthogonal - which is usually a reasonable assumption, unless you're programming a hard real-time application) Then, benchmark to find out whether the performance meets your requirements. Only if the benchmark shows that performance is too low should you optimise, and then, do so by following the guidance of your profiler. Any optimisations which you make can be checked for correctness by re-running the unit tests.