Скорость поиска QHash с использованием QStrings в качестве ключей

Question

Мне нужно нарисовать динамическое наложение на QImage. Составные части наложения определены в XML и разбираются на QHash<QString, QPicture>, где QString - это имя (например, "перекрестие"), а QPicture - это независимый от разрешения чертеж. Затем я рисую компоненты наложения по мере необходимости в позиции, определенной во время выполнения.

Пример: у меня в QHash 10 картинок, составляющих все возможные элементы в HUD. Во время определенного кадра видео мне нужно нарисовать 6 из них в разных местах на изображении. В следующем кадре что-то изменилось, и теперь мне нужно нарисовать только 4 из них, но 2 из этих позиций изменились.

Теперь к моему вопросу: если я пытаюсь сделать это быстро, я должен переопределить свой QHash как QHash<int, QPicture> и перечислить ключи, чтобы нейтрализовать издержки, вызванные сравнением строк; или сравнения не окажут большого влияния на производительность? Я легко могу выполнить преобразование в целочисленные ключи, так как синтаксический анализатор XML и оверлейный компоновщик являются полностью отдельными классами; но я хотел бы использовать согласованную структуру данных в приложении.

Должен ли я преодолеть свое стремление к последовательности и повторному использованию для повышения производительности? Будет ли это иметь большое значение, если я это сделаю?

Answer 1

Гарет имеет правильный ответ, конечно. Я хотел бы немного расширить его.

1. Перейти на последовательность и повторное использование первый. Попробуй не вводить огромный узкие места в производительности тоже; его трудно соблюсти баланс
2. Установите реалистичные критерии эффективности. Я предполагаю, что вы делаете что-то похожее на игру, разумным критерием было бы "выдерживать 25 кадров в секунду на моей машине разработчика"
3. Соответствует ли ваша заявка критериям? Да? Достаточно оптимизаций, перейдите к 5.
4. Профилируйте ваше приложение, оптимизируйте части, которые занимают больше всего времени. Вернитесь к 3.
5. Прибыль!

Возвращаясь к вашему конкретному вопросу, если число элементов в вашей хеш-таблице меньше или около ста, тип ключа, вероятно, вообще не будет иметь значения.

Answer 2

Ответ заключается в том, что вы должны профилировать свое приложение. Только если вы считаете, что сравнение строк является узким местом, вы должны реализовать альтернативную стратегию. Преждевременная оптимизация может быть пустой тратой времени.

Во-первых, убедитесь в правильности вашей программы, то есть убедитесь, что она прошла все свои модульные тесты. (Я предполагаю, что правильность и производительность ортогональны - что обычно является разумным допущением, если вы не программируете жесткое приложение реального времени). Затем проведите тестирование, чтобы определить, соответствует ли производительность вашим требованиям. Оптимизацию следует выполнять только в том случае, если тест показывает, что производительность слишком низкая, а затем выполняйте ее, следуя указаниям своего профилировщика. Любая оптимизация, которую вы выполняете, может быть проверена на правильность путем повторного запуска модульных тестов.