ListView GridView и подобные вью жрут память

[BuRn]

Добрый вечер коллеги! Давно я не обращался за помощью, но тут хз уже куда копать и что делать. Проблема следующего рода:
Имеет грид вью, на нем изначально загружено 20 элементов, остальные погружаются через fetchMore, так вот, в делегате по сути картинка и текст, он достаточно простой. Так вот, если я начинаю интенсивно подгружать элементы, т.е. двигаться по гридвью вниз так, что бы он дергал fetchMore у меня начинает расти память, за 2к элементов съедает примерно 25-30 мб памяти, для меня это существенно.  Делегаты создаются и прибиваются, примерно по 20 штук, именно те которые отображает гридвью
Проблема 1. Листвью и подобные им разве не хранят и удаляют делегат только в области видимости(во вью порте), кешбуфер не рассматриваем. Если так, то почему постоянно растет память во время fetchMore. Принудительный запуск сборщика мусора не помогает
Проблема 2. Если я выгружаю этот гридвью, с элементами, которые отожрали 20 мб, к примеру через лоадер, память не освобождается, собственно почему? Очистка кеша от энжина не помогает
Спасибо.

[vipet]

Добрый вечер коллеги! Давно я не обращался за помощью, но тут хз уже куда копать и что делать. Проблема следующего рода:
Имеет грид вью, на нем изначально загружено 20 элементов, остальные погружаются через fetchMore, так вот, в делегате по сути картинка и текст, он достаточно простой. Так вот, если я начинаю интенсивно подгружать элементы, т.е. двигаться по гридвью вниз так, что бы он дергал fetchMore у меня начинает расти память, за 2к элементов съедает примерно 25-30 мб памяти, для меня это существенно.  Делегаты создаются и прибиваются, примерно по 20 штук, именно те которые отображает гридвью
Проблема 1. Листвью и подобные им разве не хранят и удаляют делегат только в области видимости(во вью порте), кешбуфер не рассматриваем. Если так, то почему постоянно растет память во время fetchMore. Принудительный запуск сборщика мусора не помогает
Проблема 2. Если я выгружаю этот гридвью, с элементами, которые отожрали 20 мб, к примеру через лоадер, память не освобождается, собственно почему? Очистка кеша от энжина не помогает
Спасибо.

Очевидно, где-то утечка памяти. Сделайте минимальный пример, где воспроизводится проблема и покажите код. А так можно только тыкать пальцем в небо (например, при fetchMore данные у вас должны откуда-то загружаться и, вероятно, храниться в памяти, может у вас данных на 20Mb загрузилось)

Еще можно заюзать тулзы, определяющие утечки. (Например, если проект под Visual Studio, то можно Visual Leak Detector)

P.S. Qt-шные делегаты не создаются/уничтожаются постоянно, если вы их имели в виду

[Racheengel]

+1 к VLD, правда, для Qt приложения он выведет кучу бреда, смотрите в самом конце вывода - там может быть полезное.

А вообще да, странно, что у вас делегаты пересоздаются. По хорошему, их надо создать 1 раз и все.

ЗЫ. 2048-е сообщение 

[BuRn]

+1 к VLD, правда, для Qt приложения он выведет кучу бреда, смотрите в самом конце вывода - там может быть полезное.

А вообще да, странно, что у вас делегаты пересоздаются. По хорошему, их надо создать 1 раз и все.

ЗЫ. 2048-е сообщение  

Что странного то ? Эти элементы за счет чего и используются, что не создают разом элемент на каждую запись в модели, вы представляете как это было бы, если у меня в модели 5к элементов, по вашим словам он должен сразу 5к элементов создать и никогда их не удалят. Если моим словам не верите, проверьте сами, поставьте вывод в консоль на конструкторе объекта в qml и деструкторе объекта qml
С проблемой 2 совсем не понятно, как освободить потом память от листвью который ее сожрал

[Racheengel]

Так смысл делегатов в том, что создается 1 штука на столбец, или строку, или ячейку (зависит от задачи), и этот делегат тупо рисует данные (для всех ячеек по очереди), которые он берет из модели по индексу. Поэтому и странно, что они у вас создаются, а потом удаляются.

[Bepec]

А давайте посморим... Код?

[BuRn]

Да господи, простейший пример

Код:

import QtQuick 2.4
import QtQuick.Window 2.2

Window {
    id: window
    visible: true
    width: 300
    height: 300
    Component {
        id: gridDelegate
        GridView {
            id: grid
            z: -1
            anchors {
                fill: parent
            }
            cellWidth: 50
            cellHeight: 50
            focus: true
            model: 500
            currentIndex: 0
            delegate: Image {
                width: 50
                height: 50
                source: "http://www.kinopoisk.ru/images/film_big/734349.jpg"
                cache: false
                scale: grid.currentIndex == index ? 1.3 : 1
            }
            Keys.onPressed: {
                if (event.key == Qt.Key_3) {
                    grid.model = grid.model==500 ? 0 : 500
                }
            }
        }
    }
    Rectangle {
        id: rect
        anchors {
            left: parent.left
            top: parent.top
        }
        width: 100
        height: 100
        color: "red"
        property var holder
        MouseArea {
            anchors.fill: parent
            onClicked: {
                if (!!rect.holder) {
                    rect.holder.destroy()
                } else {
                    rect.holder = gridDelegate.createObject(window)
                }
            }
        }
    }
}

Нажимаем на квадрат, создается грид вью с делегатами, нажимаем еще раз, ему производится дестрой, память осталось зарезервированной, нажимаем еще раз на квадрат, он опять создает объект, память не растет, но как прибить то, что остается после destroy не понятно.

[Racheengel]

ааа, QtQuick ...
тут дебаггер бессилен

[Bepec]

ааа, qml. хз что там.

[BuRn]

Граждане, вы угораете что ли ? Раздел как бы:
Russian Qt Forum > Forum > Qt > Qt Quick

[Racheengel]

Граждане, вы угораете что ли ? Раздел как бы:
Russian Qt Forum > Forum > Qt > Qt Quick

Да я сразу как то не заметил, в этот раздел редко пишут... просто Qml очень сырой и глюкавый.
Точно знаю, что на виджетах проблем с делегатами нет.
Возможно, есть смысл решить вашу проблему попробовать с виджетами?

[Bepec]

Просто QML это ммм... скорее какая то дизайнерская штука, а не программистская.

update: если дело на винде, оно может и не убираться сразу из распоряжения процесса. Чтобы оно убиралось сразу, нужен параллельно ресурсоёмкий процесс запустить, тогда менеджер памяти все ресурсы затребует.
Если оно при повторном запросе/очистке не жрёт память, то это нормально.

[Отражение луны]

Подтверждаю, натыкался на утечку в ListView. Если правильно помню, связана она была именно с программными скроллингом листа, т.е. вызова positionViewAtEnd() и аналогичных методов.
Решение - Flickable + Repeater. По сути придется написать ListView самому с нуля, благо это делается за минут 40 и дает нехилый профит в плане контроля над поведением объектов.

Просто QML это ммм... скорее какая то дизайнерская штука, а не программистская.

Вот не нужно говорить глупостей. На qml/js можно писать серверную логику, например, и это будет крайне удобно.

[Bepec]

Вы не будете спорить, что для разработки программы на QML необходимо иметь задатки дизайнера?

[Отражение луны]

Вы не будете спорить, что для разработки программы на QML необходимо иметь задатки дизайнера?

Для разработки любого гуя нужны задатки дизайнера. Но это никак не делает сам язык дизайнерским) Например, тот же LUA.