Эффективность QListIterator?

[tguglanaklona]

Насколько QListIterator при переборе списка работает быстрее оператора QList::at ? Скажем, у меня есть перебор списков из всего 6-8 элементов, выполняющийся много раз в цикле. Каждый раз в цикле нужно создавать отдельный QListIterator (списки разные). Либо ничего не создавать и использовать QList::at. Интересует скорость работы.

[Igors]

Насколько QListIterator при переборе списка работает быстрее оператора QList::at ? Скажем, у меня есть перебор списков из всего 6-8 элементов, выполняющийся много раз в цикле. Каждый раз в цикле нужно создавать отдельный QListIterator (списки разные). Либо ничего не создавать и использовать QList::at. Интересует скорость работы.

Ничего существенного не выжать, в данном случае лучше пожертвовать "кошкиными слезами" зато писать как удобнее, хоть бы оператором [].  Но если человек вообще о производительности думает - это радует, сейчас таких мало.

[tguglanaklona]

Так вот а будут ли слёзы    ? Сколько скажем нужно элементов чтобы стало заметно - никто не проверял это? И не уходит ли лишнего на создание самого объекта QListIterator?

[Kurles]

Так вот а будут ли слёзы    ? Сколько скажем нужно элементов чтобы стало заметно - никто не проверял это?

Потрать 5 минут, проверь и отпишись )

[Swa]

Из справки:

QList is implemented in such a way that direct index-based access is just as fast as using iterators.

Edit: Если вы создаёте итераторы каждый раз из-за того, что список изменяется, то посмотрите в сторону QMutableListIterator

[Igors]

Так вот а будут ли слёзы    ? Сколько скажем нужно элементов чтобы стало заметно - никто не проверял это?

Потрать 5 минут, проверь и отпишись )

Я тоже с нетерпением жду результатов тестирования 

[tguglanaklona]

Из справки:

QList is implemented in such a way that direct index-based access is just as fast as using iterators.

Edit: Если вы создаёте итераторы каждый раз из-за того, что список изменяется, то посмотрите в сторону QMutableListIterator

Спасибо, погляжу)

[tguglanaklona]

Так вот а будут ли слёзы    ? Сколько скажем нужно элементов чтобы стало заметно - никто не проверял это?

Потрать 5 минут, проверь и отпишись )

Нееее...  пока 5 минут мои заняты  , это вопрос к теории по проблеме

[DmitryM]

В описание они используют стандартный O(f(n)), так что теоретически одинаково.
Но вся соль в том, что внутри O скрывается константа, которая везде своя.
Поэтому надо делать тесты и замерять какой метод быстрее.

[tguglanaklona]

В описание они используют стандартный O(f(n)), так что теоретически одинаково.

Спасибо.

Но вся соль в том, что внутри O скрывается константа, которая везде своя.
Поэтому надо делать тесты и замерять какой метод быстрее.

Ну это скорее от данных зависит, хотя фактически, конечно, при _одинаковом_ наборе данных для тестирования скорость алгоритмов есс-но отлична.

[DmitryM]

Ну это скорее от данных зависит, хотя фактически, конечно, при _одинаковом_ наборе данных для тестирования скорость алгоритмов есс-но отлична.

Константы зависят напрямую от реализации.

[tguglanaklona]

Ну это скорее от данных зависит, хотя фактически, конечно, при _одинаковом_ наборе данных для тестирования скорость алгоритмов есс-но отлична.

Константы зависят напрямую от реализации.

Ну да, произвольные константы и от реализации зависят, но ей не определяются 

[Igors]

Все эти рассуждения об O(n) "вообще говоря" правильны, но в данном случае неуместны. Основное правило :

- оптимизировать надо место которое является узким (на данный момент), а не то что хочется.

Ну например. Подробностей проекта я конечно не знаю,  но рискну предположить что напр QString в нем интенсивно используется. А если так то просто вызов одного конструктора QString обойдется дороже чем удастся сэкономить на 1000 "оптимальных" вызовов итератора. Кому же нужна такая экономия?

Ну и вообще, если хочется пользоваться удобными классами, то о производительности лучше помалкивать. А если кто-то начнет возникать - так приведите ему аргумент типа "скорость разработки" и.т.п.