Russian Qt Forum
Апрель 27, 2024, 17:58 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1] 2 3 4   Вниз
  Печать  
Автор Тема: ListView GridView и подобные вью жрут память  (Прочитано 23673 раз)
BuRn
Гость
« : Июль 20, 2016, 22:49 »

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

Сообщений: 452


Просмотр профиля
« Ответ #1 : Июль 21, 2016, 00:03 »

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

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

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

P.S. Qt-шные делегаты не создаются/уничтожаются постоянно, если вы их имели в виду
Записан
Racheengel
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2679


Я работал с дискетам 5.25 :(


Просмотр профиля
« Ответ #2 : Июль 21, 2016, 01:46 »

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

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

ЗЫ. 2048-е сообщение  Веселый
Записан

What is the 11 in the C++11? It’s the number of feet they glued to C++ trying to obtain a better octopus.

COVID не волк, в лес не уйдёт
BuRn
Гость
« Ответ #3 : Июль 21, 2016, 10:43 »

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

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

ЗЫ. 2048-е сообщение  Веселый
Что странного то ? Эти элементы за счет чего и используются, что не создают разом элемент на каждую запись в модели, вы представляете как это было бы, если у меня в модели 5к элементов, по вашим словам он должен сразу 5к элементов создать и никогда их не удалят. Если моим словам не верите, проверьте сами, поставьте вывод в консоль на конструкторе объекта в qml и деструкторе объекта qml
С проблемой 2 совсем не понятно, как освободить потом память от листвью который ее сожрал
« Последнее редактирование: Июль 21, 2016, 10:45 от BuRn » Записан
Racheengel
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2679


Я работал с дискетам 5.25 :(


Просмотр профиля
« Ответ #4 : Июль 21, 2016, 10:53 »

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

What is the 11 in the C++11? It’s the number of feet they glued to C++ trying to obtain a better octopus.

COVID не волк, в лес не уйдёт
Bepec
Гость
« Ответ #5 : Июль 21, 2016, 11:03 »

А давайте посморим... Код? Веселый
Записан
BuRn
Гость
« Ответ #6 : Июль 21, 2016, 14:17 »

Да господи, простейший пример
Код:
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
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2679


Я работал с дискетам 5.25 :(


Просмотр профиля
« Ответ #7 : Июль 21, 2016, 14:33 »

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

Записан

What is the 11 in the C++11? It’s the number of feet they glued to C++ trying to obtain a better octopus.

COVID не волк, в лес не уйдёт
Bepec
Гость
« Ответ #8 : Июль 21, 2016, 14:35 »

ааа, qml. хз что там.
Записан
BuRn
Гость
« Ответ #9 : Июль 21, 2016, 14:49 »

Граждане, вы угораете что ли ? Раздел как бы:
Russian Qt Forum > Forum > Qt > Qt Quick
Записан
Racheengel
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2679


Я работал с дискетам 5.25 :(


Просмотр профиля
« Ответ #10 : Июль 21, 2016, 14:52 »

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

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

What is the 11 in the C++11? It’s the number of feet they glued to C++ trying to obtain a better octopus.

COVID не волк, в лес не уйдёт
Bepec
Гость
« Ответ #11 : Июль 21, 2016, 14:58 »

Просто QML это ммм... скорее какая то дизайнерская штука, а не программистская. Улыбающийся

update: если дело на винде, оно может и не убираться сразу из распоряжения процесса. Чтобы оно убиралось сразу, нужен параллельно ресурсоёмкий процесс запустить, тогда менеджер памяти все ресурсы затребует.
Если оно при повторном запросе/очистке не жрёт память, то это нормально.
« Последнее редактирование: Июль 21, 2016, 15:45 от Bepec » Записан
Отражение луны
Гость
« Ответ #12 : Июль 22, 2016, 00:17 »

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

Вот не нужно говорить глупостей. На qml/js можно писать серверную логику, например, и это будет крайне удобно.
« Последнее редактирование: Июль 22, 2016, 00:20 от Komorebi » Записан
Bepec
Гость
« Ответ #13 : Июль 22, 2016, 10:18 »

Вы не будете спорить, что для разработки программы на QML необходимо иметь задатки дизайнера? Веселый
Записан
Отражение луны
Гость
« Ответ #14 : Июль 23, 2016, 14:57 »

Вы не будете спорить, что для разработки программы на QML необходимо иметь задатки дизайнера? Веселый
Для разработки любого гуя нужны задатки дизайнера. Но это никак не делает сам язык дизайнерским) Например, тот же LUA.
Записан
Страниц: [1] 2 3 4   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.051 секунд. Запросов: 22.