QHash vs QList. Один уродует порядок, другой тормозит..., Нужен быстрый доступ, но без сортировки объектов |
Здравствуйте, гость ( Вход | Регистрация )
QHash vs QList. Один уродует порядок, другой тормозит..., Нужен быстрый доступ, но без сортировки объектов |
demon051 |
14.6.2018, 10:46
Сообщение
#1
|
Студент Группа: Участник Сообщений: 27 Регистрация: 12.8.2014 Пользователь №: 4209 Спасибо сказали: 4 раз(а) Репутация: 0 |
Всем привет!
Попал вот в неприятное... В общем гружу из таблицы БД данные. Каждая строка превращается в объект в памяти. Надо куда-то сохранять. Почитал доку по QHash, там написано что он не сортирует заносимые в него данные. Ага, на... В итоге оказалось, что он не сортирует, но раскидывает в каком-то удобном ему порядке, возможно, для осуществления быстрого поиска по ключу. А мне надо, чтобы порядок был тот самый, в котором я загружаю (order by - в sql-запросе). Ну я подозревал по предыдущему опыту, что c QList будет доступ к данным тормознее, но оказалось, что жутко тормознее. Фактически для поиска нужного объекта в QList надо каждый раз всё перебирать. Соответственно, чем больше объектов и чем глубже лежит нужный, тем всё хуже и хуже скорость Чешу репу, думаю что делать... чтобы получить не сортированный порядок объектов с возможностью быстрого поиска нужного. Ищется по уникальному Id, который в QHash использовался в качестве ключа. А в QLict - перебор со сравнением для каждого Id. Help me!!! Please!!! |
|
|
Sokoloff |
14.6.2018, 11:21
Сообщение
#2
|
Участник Группа: Участник Сообщений: 237 Регистрация: 1.4.2009 Из: Москва Пользователь №: 654 Спасибо сказали: 50 раз(а) Репутация: 11 |
Чешу репу, думаю что делать... чтобы получить не сортированный порядок объектов с возможностью быстрого поиска нужного. Ищется по уникальному Id, который в QHash использовался в качестве ключа. А в QLict - перебор со сравнением для каждого Id. А что такое "не сортированный порядок объектов"? Ведь не совсем не сортированный, иначе и QHash подошел бы. Если нужно сортированное по ID, то можно взять QMap, он чуть медленнее чем QHash, но отсортирован по ключу. Если это не подходит, то можно сделать свой класс, он хранит объекты в QList/QVector, но еще хранит пары ID->номер строки в QHash. Или, если объекты хранятся как указатели, можно хранить указатель на один объект и в QList и в QHash. |
|
|
demon051 |
15.6.2018, 8:51
Сообщение
#3
|
Студент Группа: Участник Сообщений: 27 Регистрация: 12.8.2014 Пользователь №: 4209 Спасибо сказали: 4 раз(а) Репутация: 0 |
Чешу репу, думаю что делать... чтобы получить не сортированный порядок объектов с возможностью быстрого поиска нужного. Ищется по уникальному Id, который в QHash использовался в качестве ключа. А в QLict - перебор со сравнением для каждого Id. А что такое "не сортированный порядок объектов"? Ведь не совсем не сортированный, иначе и QHash подошел бы. Если нужно сортированное по ID, то можно взять QMap, он чуть медленнее чем QHash, но отсортирован по ключу. Если это не подходит, то можно сделать свой класс, он хранит объекты в QList/QVector, но еще хранит пары ID->номер строки в QHash. Или, если объекты хранятся как указатели, можно хранить указатель на один объект и в QList и в QHash. не сортированный - это так, как я из загрузил. а не так как захотел хэш или мап. они все сортируют по своему. хотя в доке прямым текстом указано, что хэш не сортирует |
|
|
Sokoloff |
15.6.2018, 20:08
Сообщение
#4
|
Участник Группа: Участник Сообщений: 237 Регистрация: 1.4.2009 Из: Москва Пользователь №: 654 Спасибо сказали: 50 раз(а) Репутация: 11 |
хотя в доке прямым текстом указано, что хэш не сортирует Это не совсем такWhen iterating over a QMap, the items are always sorted by key. With QHash, the items are arbitrarily ordered. http://doc.qt.io/qt-5/qhash.html Это надо понимать так, для ускорения мы хэшируем ключи, и храним значения в порядке который дает максимальную скорость поиска по этим хэшам. Для человека это выглядит как произвольный/случайный порядок. QMap просто сохраняет отсортировано по ключам. И потом ищем по ним, возможно что-то вроде бинарного поиска. Но это несколько медленнее чем поиск по хэшам. не сортированный - это так, как я из загрузил. а не так как захотел хэш или мап. они все сортируют по своему. Подход зависит от того как ты хранишь данные. Если хранишь указатели, то все проще. хотя в доке прямым текстом указано, что хэш не сортирует Я бы написал класс DataStorage внутри у него QVector. Также класс умеет создавать индекс для поиска, индекс это QHash<ID, yourRowData*>. Т.е. данные не дублируются, но указатели на данные храняться и в порядке добавления, и удобно для быстрого поиска. У класса есть методы: * addRow - добавляет указатели и в вектор и в индекс * deleteRow - удаляет из обоих * count - кол-во строк * row(int) - возвращает строку по номеру, использует вектор * search(ID) - возвращает строку по ID, использует QHash Ну а дальше можно развивать, можно иметь несколько индексов и.т.д. demon051, то есть, ты сортируешь по параметру "порядок загрузки". В этом случае идеально подходит QVector Это зависит от способа хранения, если demon051 хранит указатели, да еще и доступается по номеру строки, то вектор. А если хранит сами данные по значению, да еще и данных много, то для QVector-а может не хватить памяти одним куском. а QList - вообще бесполезный, на мой взгляд, контейнер для хранения больших объёмов данных. |
|
|
Текстовая версия | Сейчас: 22.11.2024, 16:36 |