Russian Qt Forum

Всем привет.
Вопрос растёт вот откуда: пишу прогу конвертер. Так как оперативы хватает, с промежуточными данными не заморачиваюсь. Прога при работе создаёт порядка полумиллиона динамических структур, которые держит в оперативе. В каждой структуре сидит поле QByteArray. Так вот. Если я собираю эту прогу с библиотекой 5.2.1, которая из репозиториев ubuntu 14.04 64-bit, при работе она хавает около 200 метров оперативы. А вот если собираю её с библиотекой 5.6.1, которую сам компилил во всё той же убунте, она на тех же данных жрёт гиг. Ради интереса проверил под виндой 7, там стоит тоже 5.6.1, но не самосборная, бинарниками ставил с mingw32, там хавает ещё меньше, чуть больше 150 метров.
Вот я и думаю, собраться библиотека у меня собралась, но в дефолтных настройках сборки стоит слишком большая цифра, сколько памяти изначально жрать под пустой QByteArray. Кто-нибудь сможет подсказать как решить эту проблему?

Слишком большая цифра чего?
Объема пустого места занимаемого QByteArray? Врядли.
Тут может влять выравнивание, но это уже вопрос к компилятору.

Интересная версия...
Я собирал системным компилятором, никаких линаро и тому подобных приблуд не ставил. И я подозреваю, что репозиторная библиотека собрана им же.
По поводу циферки может и не правильно выразился. Имелась в виду циферка - размер запрашиваемой по дефолту памяти у ядра для размещения динамического объекта. Я не очень хорошо понимаю эту механику, но где-то читал, что для объектов с изменяющимся размером данных, типа QByteArray, изначально запрашивается кусок памяти определённого размера. Или выделяется в уже имеющейся куче. С учётом прогнозируемого роста размера данных. Причём непрерывный. Даже для пустого объекта. И я подозреваю, что моя сборка для каждого QByteArray просит раза в 4 больше места, чем системная сборка. И в итоге это место тупо не используется. Средний размер моих QByteArray'ев 32 байта. Вопрос сколько выделяется под пустышку? И как это поправить. Скорее всего есть какой-то дефайн, скармливаемый компилятору (-DDEFINENAME=value), который за это отвечает.
А с выравниванием врядли, что там, что там 4 байта стоит, специально проверил, #pragma(pack) не пользовал.
С другой стороны эти байтмассивы лежат в QMap. А вот тут наверное актуален вопрос выравнивания. Но как это хотя бы проверить?
Попробую завтра запихать в QMap указатели вместо объектов, вдруг поможет... Если потребление вырастет не сильно (QMap'ов всего 7, а вырастет имхо за счёт того что ещё полляма указателей кроме всего прочего хранить нада), значит моя первоначальная версия правильная.
Проверил на Cortex-a9, тоже самосборная библиотека 5.6.1, жрёт ~170 метров...\
Вопрос в чём разница?

Вот в доке стоит такое:

When you append() data to a non-empty array, the array will be reallocated and the new data copied to it. You can avoid this behavior by calling reserve(), which preallocates a certain amount of memory. You can also call capacity() to find out how much memory QByteArray actually allocated. Data appended to an empty array is not copied.

можно попробовать reserve(32) и посмотреть, что говорит capacity() ...

append'ов нету, тупо QFile::readLine(). Дальше это путешествует по функциям в виде const QByteArray &.
Но завтра буду пытать все версии

Узнайте "из первых рук" QByteArray::capacity

QByteArray::squeeze() хотя она может и не освобождать память (в старых OC так было)

как это ?

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

А попробуйте собрать с mingw64, интересно, сколько такая сборка будет потреблять.

Может банально debug версия собрана вручную?
И подгружается куча отладочной информации?

Всем привет.
Короче провёл кучу экспериментов, ни один разницы не показывает... Только моя прога на 5.6 столько жрёт. Теперь уже можно утверждать, что либа не обязательно должна быть самосборной. Установил в линукс официальный бинарник 5.6.1, картинка таже. В Ubuntu 16.04 64-bit в репах лежит версия 5.5.1, там нормально всё с памятью. Выше - жрёт. Но в винде 5.6 не жрёт, mingw64 компилится (надеюсь соберётся), посмотрю ещё там.
Насчёт дебага - хз. При компиляции библиотеки указываю опцию -release. При компиляции самой проги в дебаге растёт её бинарник, работает немного медленнее, но потребляемая память одинаковая.

QByteArray::capacity что говорит?

Qt 5.2.1 x64 Ubuntu
0
7
39
Qt 5.6.0 x64 Ubuntu
0
7
39
Qt 5.6.1 x32 buildroot linux Cortex-a9
0
15
15

Получается, что QByteArray как бы и не при чем..?
Кстати, а SVG-иконки случайно нигде не используются?
С ними у Qt проблемы с т.з. памяти.

А вот это "сожрало" - его никак нельзя детализировать? Напр в OSX есть штатное средство чтобы посмотреть какие блоки памяти приложение выделяло и сколько. Может само приложение жрет везде одинаково, а привязалась какая-то либа

А вот этого и мне хотелось бы... Только не знаю как. Пользую QtCreator 4.0.2 (Тоже самосборный ))))

Для профилирования потребления памяти можно воспользоваться valgrind massif.

Ну тогда (для полноты картины) интересно узнать - а что же есть на "неубогом" Вындоуз?  :)

http://stackoverflow.com/questions/131303/how-to-measure-actual-memory-usage-of-an-application-or-process

упоминаемая там pman выводит детально

Гугл выдаёт https://blogs.msdn.microsoft.com/visualstudioalm/2014/04/02/diagnosing-memory-issues-with-the-new-memory-usage-tool-in-visual-studio/ (https://blogs.msdn.microsoft.com/visualstudioalm/2014/04/02/diagnosing-memory-issues-with-the-new-memory-usage-tool-in-visual-studio/)

чё там ТС разобрался кто память поел ?