Отвечаю в корень, так как это ответ на несколько постов.

Сделал const_iterator и запомнил indices.end() , чтобы не дёргать её в цикле (казалось бы, это должно было соптимизироваться, но ладно, запомнили вручную).

Всё равно время работы удивляет:

Один из отчётов по времени работы:
count = 5977 (max_index) 3322 (indices.size) — полный перебор почти 6000 интов, а хеш-множестве почти в 2 раза меньше
point1 dt= 2.2303e-05 — полный перебор циклом с проверкой наличия индекса в множестве
point2 dt= 5.9156e-05 — перебор константным итератором по хеш-множеству

Опять, перебор по множеству оказался почти в 2 раза медленнее. Конечно, уменьшение объёма в этот раз не существенное, но выходит, что итерирование по QSet'у как минимум в 4 раза медленнее итерации по целым числам.

Вот ещё один отчёт:


count = 83 (max_index) 4 (indices.size)
point1 dt= 6.87e-07
point2 dt= 1.453e-06

Объём множества в 20 раз меньше, а время всё равно оказалось в 2 раза больше при итерации по множеству...

Ещё пример (в предыдущем может так оказаться, что из-за очень малых объёмов накладные расходы на инициализацию цикла перекрыли выгоду):

count = 2434 (max_index) 310 (indices.size)
point1 dt= 7.236e-06
point2 dt= 1.0598e-05

При уменьшении перебора почти в 7 раз время работа выросло, ну хоть не в 2 раза, но всё равно существенно...

Это очень странно, либо хеш-множество реально много накладных расходов влечёт, либо я где-то очень неслабо накосячил... Проверить на косячность Qt'шную реализацию QSet'а не могу (в 11 стандарт нам нельзя, проект за 10 минут не поправлю, чтобы собрать с -std=c++11)... Можно попробовать сделать свою реализацию множества, но сомнительно, что свой велосипед обгонит библиотеку (если только у Qt нет какого-то косяка, всякое бывает).

PS. Версия Qt у нас 4.8