Russian Qt Forum

Привет, друзья!
Создал свою табличную модель. Маленькие объёмы обрабатывает хорошо. А вот с большими происходит выброс.

C++ (Qt)
    tbl = new TableModel(this);
    tbl->setColumnCount(ui->columnsSpn->value());
    tbl->setInputData(rawData);     //QByteArray
    tbl->setBeginAddress(rawPos);
    ui->rawTbl->setModel(tbl);
 

На каждую функцию модели я повесил qDebug
Подскажите, пожалуйста, почему у меня выскакивает ошибка. Точнее, какие пределы по строкам в таблице? Или как оптимизировать таблицу.

Обычно очень много данных хранят в какой-нибудь БД и предоставляют доступ с помощью SQL model (http://qt-project.org/doc/qt-4.8/sql-model.html) :)

Данные хранятся в файле. Как-то менять этот файл нельзя. Можно создавать временные файлы.
Конечная цель: вывести в таблицу полученный массив char. Количество колонок определяет пользователь.
С базами опыта на qt не имел. Как прикрутить мою задачу к этому классу не понимаю.

Ок. Допустим, я во временный файл запишу базу sqlite. Есть ли гарантия того, что таблица сумеет вывести мне все значения?

Никогда ни 1 человеку не понадобятся все данные :)
Это заблуждение. Потому надо давать маленькими частями и организовать ленивую загрузку :)

Согласен.
Что вы имели в виду под "давать маленькими порциями"? Это подразумевает дополнительные действия от пользователя?

33 ляма строк - это не так много. скорее всего, проблема в том, что вы сами данные храните в векторе. Тогда надо выделить сплошной кусок памяти размера 33ляма умножить на размер структуры. Если заменить вектор структур на вектор указателей на структуры, памяти потребуется больше, но не одним куском. Можно просто заменить вектор на кулист, он уже использует указатели на данные.

Судя по сигнатуре и по наличию вектора, в качестве модели используется QStandardItemModel, а она не предназначена для большого количества данных.

Мои данные хранятся в QByteArray.
Этот массив выводится в таблицу. По одному значению в ячейку.
Если колонок в таблице сделать 5, то вылета не будет.
Наследуюсь от QAbstractTableModel

Тебе проще сделать минимальный компилябельный пример, а мы его посмотрим и поможем. ;)

Вот (см. аттач)
цифру можно указать и меньшую, ели добавить какую-нибудь информацию в методы data и headerData.

Может, 990000000 слишком много? :) Убрал один 0 и все заработало. А так, падало где-то внутрях байтаррея.

Эээх :)
Придётся модифицировать свой пример, чтобы показать проблему (даже без последнего ноля)...

Скорее всего, ибо тут эта проблема не воспроизводится.

Пользователю нужно максимум 900 строк на экране. Именно их вы и должны хранить в программе.
Остальное должно лежать допустим в базе данных и запрашивать по требования.

Допускается так же 900 строк вверх и 900 строк вниз от имеющихся для "плавной" прокрутки.

PS Вылетает скорее всего изза предела в 2 Гб для x32 программы.

В точку по поводу x32. Но насчёт 2 Гб - не знаю как устроены классы, но потребление в аттаче
Откомпилировал свой проект под msvc 2013 с Qt 5.3.1 opengl 64 и мой большой файл открылся без проблем. К сожалению нет возможности проверить работу при msvc x32 компиляторе. Но, думаю, что там будет то же.

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

В 32 архитектуре процессу доступно только 2 GB оперативы. Я тоже склоняюсь, что проблема в этом.

Под вендой.
В linux - 3 Gb.

Да, забыл уточнить. Спасибо. :)

Спасибо за ответы.
Немного стыдно, что не знал про 2ГБ. Я был уверен, что выделяется до 4ГБ, если приложение запустить из-под x64

А как отлавливать такие исключения? Куда цеплять try?

Под виндой это довольно запутанно и сложно :D

Имеется вроде бы блок для ловли таких вот гадостей в __try.

ИМХО, под виндой такое сложно отловить. Нужно изначально разрабатывать, чтобы не превышать лимитов.

Так понимаю, лимиты подбираются на ощупь в моем случае.

А еще интересно вот что!
Если я беру этот же массив и вывожу не в одну колонку, а в 3, то ошибка не выскакивает.

Ну, смотри, Куьют из скулайтной базы подтягивает данные по 256 строк. Можешь так примерно и сделать. Пользователю не нужно видеть мульоны строк, ему нужно 100 +- 50 максимум. А дальше можно отфильтровать.

Как при этом должен работать скроллбар? Если я захочу потянуть за него?
Он должен просто иметь 3 положения: верх, низ и середина?

Хм. По-идее, можно размер передавать реальный, а вот в памяти держать только нужные данные. Вьюха не запрашивает данные для ячеек, которые не видны. Исключением будет если ты пытаешься сделать ресайз колонок под содержимое - тогда делается пробег по всем значениям.

У меня 5.3 и вьюха, как мне кажется, делает пробег по всем колонкам/строкам (скрытым и отображенным). Более того, она делает это мультипоточно.

Одни и теже данные я пытаюсь отобразить в 3 колонки, а затем в 1. Ничего не меняю в памяти кроме nColumns и nRows.
При отображении в 3 все ок. А при отображении в 1 выброс.
Также я вешал на методы data, headerData функцию qDebug(). Она вызывалась много большее число раз, чем строк имеется в отображении.

Прокси?
Ресайз политика колонок/строк?

Использую QTableView с настройками по умолчанию

Можешь сам проверить - в тестовом своем примере замени:

C++ (Qt)
QVariant data(const QModelIndex &index, int role) const{static int i = 0; i = qMax(i, index.row ()); return (role == Qt::DisplayRole) ? QString::number (i): QVariant();}
 

и увидишь, что там появится номер для видимых ячеек (ну, возможно, плюс еще парочка). А вот если в main сделать:

C++ (Qt)
w.show();
w.resizeColumnsToContents ();
 

То увидишь максимальное количество строк.

Не понимаю, в чём дело...
Сделал в своем примере

C++ (Qt)
    QVariant data(const QModelIndex &index, int role) const
    {
        static int i = 0;
        if (role == Qt::DisplayRole)
        {
            qDebug() << ++i;
            return i;
        }
        return QVariant();
    }
 

Да. убедился, что все именно так.
А когда вставил это же в свой проект и при открытии большого файла получил такое:
Если что, первые 60 qDebug() относятся к другой mv

Значит проблема в чем-то еще.
Покажи свой метод data.

C++ (Qt)
    if (!index.isValid() || (role != Qt::DisplayRole && role != Qt::EditRole))
        return QVariant();
 
    int id = index.row() * nColumns + index.column();
    int arrayOffset = id * typeSize[type] + offset;
    if (arrayOffset + typeSize[type] > dataArray->size())
        return QVariant();
 
    const char* pointer = static_cast<const char*>(dataPtr) + arrayOffset;
 
    switch (type)
    {
    case Hex:
        return QString("%1").arg(reinterpret_cast<const uchar*>(pointer)[0], 2, 16, QChar('0')).toUpper();
    ....
    return QVariant();
 

В качестве типа приходит Hex

typeSize[type] - тут нет выхода за пределы массива?

нет. это хэш, который принимает перечисление.

Я бы на твоем месте начал с проверки корректности вычисления id и arrayOffset.

Да с ними всё в порядке. Маленькие файлы открываются хорошо. Этот большой, на котором вылет происходит, тоже хорошо, но только с выводом минимум в три колонки. Значения, которые выводятся в таблице я все вручную проверял.

А размер QByteArray какой на этом файле?

Это и есть размер массива.

32 МБ многовато. Возможно, QByteArray просто переполняется. Попробуй не закачивать файл в оперативку, а замаппить его. Или хранить только часть и подтягивать данные, если они понадобились.

Еще есть предположение - QByteArray хранит данные единым блоком, поэтому, если блок не получается выделить, будет сбой. Если приложение (32 битное) даже не ест все 2 гига, есть такая вещь, как фрагментация памяти.

Грубо говоря нереально открыть файл размером около 250Мб и вывести в колонку его хекс значения по байтам.
Я с этим сталкивался и в другой задаче.

если я закомментирую строчку привязки модели к вьюхе, то QByteArray справляется. Даже метод QFile::readAll читает файлы до 250Мб и возвращает QByteArray.

Сейчас посмотрел в хирер qvector.h - та строчка относится к реалоку. то есть, у тебя какое-то перераспределение памяти, на котором происходит падение...

type ты откуда берешь? Что-нибудь еще изменяется в методе data?

При наличии большего числа колонок (что уменьшает количество строк. в данном случае втрое) предотвращает ошибку. Это дает право сказать, что QByteArray тут не при чем

Нехватка памяти, полагаю

Сама вьюха тоже, наверное, на векторах стоит

Попробуй еще утечки поискать памяти.

Визуально я это проделал. И моё эго подсказывает, что я очень щепетильно расходую память :)
Специальным софтом ни разу не пользовался. Посоветуете бесплатную? (Работаю в QtCreator, но есть и MSVS 2013 x64)

valgrind, но это только под Линухом.

Жаль. Мне линукс ставить отказываются (как и vm), а дома не вариант.

Мне повезло повторить ошибку в минимально компилябельном примере (см. аттач)!
Всё что нужно - открыть файл свыше 120Мб (но из-за readAll не более 250). Будет точно такой же вылет.
Мелкие файлы читаются на ура.

Пробежавшись в дебаге по тестовому примеру из сообщения (http://www.prog.org.ru/index.php?topic=27927.msg203600#msg203600) (это где rowCount = 990000000),
можно увидеть, что падение происходит в функции (qbytearray.cpp):

C++ (Qt)
int qAllocMore(int alloc, int extra)
{
    Q_ASSERT(alloc >= 0 && extra >= 0);   // line: 72        alloc = -669934592
...
}
 

причем вызывается функция из (qarraydata.cpp):

C++ (Qt)
    if (options & Grow)
        capacity = qAllocMore(int(objectSize * capacity), int(headerSize)) / int(objectSize);     // line: 97
 

где: objectSize = sizeof(QHeaderViewPrivate::SectionItem) = 8 и capacity = 990000000

вывод 1: возможно есть баг в том, что в функцию qAllocMore передается размер в int (даже не в uint). Надо разбираться
вывод 2: для отображения большого количества данных необходимо писать свой View

То зависание, скорее всего, не относится к моей проблеме. Так совпало, что мне удалось и его выявить :)
qAllocMore у меня тоже один раз выскочила с ошибкой, наверное открыл файл чуть больше обычного.

для отображения большого количества данных можно добавить колонки и размазать данные по ним, уменьшив количество строк, но это только для моей истиной проблемы. Как увеличение колонок и уменьшение строк поведут себя в том проекте - не проверял.

В предыдущем сообщении проблема, которая реально стоит в моем проекте.

Можно еще попробовать заюзать QAbstract* модель и вьюху.

То зависание будет отрабатывать в релизной версии с отключенными ASSERT

К сожалению, я ещё малоопытен чтобы превращать QAbstract во что-то визуальное типа вьюхи.

Попробуй для начала реализовать можель не от TableModel, а от абстрактной.

Все та же проблема, одним большим непрерывным куском память не выделяется.
Попробуйте читать файл кусками или воспользоваться методами QFile::map, QFile::unmap в модели унаследованной от QAbstractItemModel

Под хранение данных из файла в QByteArray у меня все выделяется. Не совсем понимаю, как метод хранения данных может повлиять на представление.
Если же не прикручивать модель к представлению и открыть все тот же файл, то все откроется без ошибок.
В этом можно убедиться на примере из моего прошлого сообщения (http://www.prog.org.ru/index.php?topic=27927.msg203732#msg203732)

А если потом у модели позапрашивать вручную данные?

Вы же писали про 250 Мб:
Этим сообщением:
я как раз о 250 и выше говорил.

Да, говорил. Но это относится к функции file.readAll().
Поправьте меня, если я ошибаюсь, но эта функция не умеет читать большие файлы. Вместо нее мы можем читать файл порциями и добавлять в память прочитанные блоки.

Умеет, но:


Об этом я тоже писал.

P.S. И вообще при возникновении ошибки, попробуйте до нее "дотопать" отладчиком, благо, что исходники Qt есть. Как раз много нового узнаете, и прокачаете свой скил.

Что-то заинтересовал вопрос.
Возможно ли написать свой memcpy (memcpyX86) на asm, который будет работать быстрее стандартного? Или же компиляторы и так её делают максимально эффективной?