Qlist подходит для использования в сервисе?

Я создаю программу на C++, которая будет работать как служба (под Linux), и я использую Qt из-за множества удобных методов. Я использую QList для отслеживания элементов, которые будут добавляться и удаляться из qlist в течение многих месяцев. (С потенциально сотнями добавлений/удалений в день).

Основываясь на моем недавнем чтении, кажется, что QList никогда не уменьшается - они только растут с точки зрения использования памяти (пока весь QList не будет освобожден). Делает ли это QList непригодным для использования в приложении, которое работает бесконечно?

Придется ли мне вместо этого создавать собственный связанный список? Или есть способ «сжать»/очистить память, используемую в QList?

Обновление: исходя из приведенных ниже отзывов, QLinkedList предпочтительнее? (Освобождает ли он сразу память, когда член списка "стирается")


c++ qt memory qlist
person TSG    schedule 27.01.2014    source источник
comment
Ой! Не знал этого о QList. Где ты это прочитал?   -  person davepmiller    schedule 27.01.2014
comment
QList - это функция Qt (библиотека C++)   -  person TSG    schedule 27.01.2014
comment
@laser_wizard так сказано в документации, однако QList использует T*[] (массив указателей на T) для хранения данных, так что не все так плохо   -  person ratchet freak    schedule 27.01.2014
comment
похоже, у @ratchetfreak есть хорошая информация :)   -  person davepmiller    schedule 27.01.2014
comment
Вы на самом деле измерили использование памяти QList и определили его как нечто, о чем вам нужно беспокоиться, или это просто программирование карго-культа? На платформе с 64-битными указателями, как правило, QList имеет около 1 КБ служебных данных на 100 больших элементов (больше 8 байт). Эти накладные расходы масштабируются с максимальным количеством элементов, одновременно хранимых в списке. Так, например, если вы храните в списке не более 1000 элементов, накладные расходы никогда не превысят 10 КБ. Я думаю, что беспокоиться об этом - пустая трата времени. Если вы утверждаете обратное, поделитесь с нами своими измерениями и результатами.   -  person Kuba hasn't forgotten Monica    schedule 28.01.2014
comment
Я понятия не имею, что такое «карго-культ» программирования. Я пытаюсь избежать построения этого неправильного пути... в отличие от неправильного построения, обнаружения неконтролируемого роста памяти, отслеживания Qlist, а затем задавания вопросов. В этом случае элементы в списке постоянно меняются, поэтому кажется, что QList будет бесконечно увеличиваться в размере (пока объект не будет уничтожен). В этом случае QLinkedList будет лучше обрабатывать память. (Если программирование «культа грузов» означает поиск лучших инструментов для каждой работы, то да, это я)   -  person TSG    schedule 29.01.2014

Ответы (2)


arrow_upward
4
arrow_downward

Qt имеет собственный QVector и QLinkedList.

QVector имеет функцию squeeze, которая при необходимости освобождает неиспользуемую память.

person ratchet freak    schedule 27.01.2014
comment
Из дальнейшего чтения кажется, что у QVector много накладных расходов на добавление/удаление. (Мой список претерпевает быстрые изменения). Поскольку я добавляю только в конец списка, делает ли это предпочтительным QLinkedList? - person TSG; 27.01.2014
comment
@Michelle зависит от того, где вы добавляете и удаляете, есть и другие контейнеры классы, реализованные в Qt (а также в стандартной библиотеке C++) - person ratchet freak; 27.01.2014
comment
Я все еще новичок в Qt, поэтому стараюсь избегать дальнейшего обучения (уже перегружен Qt). Я вижу, что QLinkedList не имеет команды сжатия, значит ли это, что он всегда немедленно освобождает неиспользуемую память (при вызове стирания)? Так что это будет казаться лучшим - person TSG; 27.01.2014
comment
@Michelle QLinkedList немедленно освобождает неиспользуемую память - person ratchet freak; 27.01.2014

arrow_upward
2
arrow_downward

Какое «чтение» натолкнуло вас на мысль о QList? Если бы он никогда не освободил бы неиспользуемую память, это бы фактически привело к утечке памяти, а это не так.

QList внутренне реализован как вектор указателей. Когда объект достаточно мал, чтобы поместиться в то же количество байтов, что и указатель, список эквивалентен QVector. Внутренний вектор возможно не сжимается, но на практике это не имеет значения. Это всего 4 или 8 байтов на элемент, и он ограничен общим количеством элементов, присутствующих в списке. Скорее всего, это красная селедка.

person Kuba hasn't forgotten Monica    schedule 27.01.2014
comment
Вероятно, та часть документации QList, в которой говорится: Note that the internal array only ever gets bigger over the life of the list. It never shrinks. The internal array is deallocated by the destructor and by the assignment operator, when one list is assigned to another. - person thuga; 28.01.2014
comment
@thuga Этот внутренний массив хранит 4-8 байтов на элемент. Неважно, что он никогда не сжимается, если вы не храните очень маленькие элементы. Хранилище, занимаемое всего несколькими элементами приличного размера, затмит любое пространство, используемое массивом. - person Kuba hasn't forgotten Monica; 28.01.2014
comment
Как я упоминал выше, я добавляю и удаляю сотни элементов в день. Если эта служба работает в течение года, она потенциально может потреблять много памяти. (И в целом приложение, которое постоянно потребляет больше памяти, звучит не очень хорошо). В документах также говорится, что добавление в QVector приведет к тому, что весь массив элементов будет скопирован в новый массив, чтобы сохранить последовательную память; звучит как плохая посадка при постоянном добавлении и удалении элементов). QLinkedList звучит как победитель!? - person TSG; 29.01.2014
comment
@Michelle: Нет! Накладные расходы памяти масштабируются с максимальным значением list->size(). Это все. Неважно, сколько элементов вы добавляете и удаляете. Вы потребляете около 8*list->size() (на платформах с 64-битными указателями) накладных расходов, и эти накладные расходы только растут, а не уменьшаются. Таким образом, важно не то, сколько элементов вы добавляете или удаляете, а сколько элементов находится в списке одновременно. QLinkedList имеет еще более высокие накладные расходы - как минимум 24*list->size(), но эти накладные расходы могут снизиться. - person Kuba hasn't forgotten Monica; 29.01.2014
comment
@Michelle: Опять же, вам лучше иметь надежные измерения, чтобы показать, что это проблема. В противном случае это просто пустая трата времени. Вам нужна структура данных, с которой легко работать. Беспокойтесь о накладных расходах, когда ваши тесты показывают, что накладные расходы имеют значение. - person Kuba hasn't forgotten Monica; 29.01.2014
comment
@Michelle: Например, если список никогда не содержит более 1000 элементов одновременно, то в худшем случае накладные расходы составляют около 16 КБ, независимо от того, как долго список используется. Если вы используете связанный список, эти накладные расходы составят около 24 КБ в худшем случае, и вы получите структуру, которую сложнее использовать, потому что вы больше не можете индексировать ее целыми числами. - person Kuba hasn't forgotten Monica; 29.01.2014
comment
@KubaOber Да, я знаю. Я просто указал, какая часть дала ОП идею QList не освобождать память. - person thuga; 29.01.2014