QTextEdit, тормозит Опции

[BRE]

А зачем флаг QIODevice::WriteOnly? Он же потом из потока читать будет.

А зачем из него читать, все данные в QByteArray.

Да и скорость потока это не главная проблема тормозов. Время парсинга у меня занимает точно такое же как и с QString - 5062мс (debug), 3313мс (release).

Это уменьшает количество реалокаций памяти и уменьшает дефрагментацию кучи. Ну и небольшое ускорение дает, за счет уменьшения копирования буфера строки после реалокаци.

[SABROG]

А зачем из него читать, все данные в QByteArray.

Ладно, а зачем ты тогда в свой код вставил вообще QTextStream ?

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

#include <QtGui/QApplication>
#if 0
#include <QtGui/QPlainTextEdit>
typedef QPlainTextEdit TextEdit;
#else
#include <QtGui/QTextEdit>
typedef QTextEdit TextEdit;
#endif

#include <QtCore/QtGlobal>
#include <QtCore/QtDebug>
#include <QtCore/QTime>

#include <QtCore/QFile>
#include <QtCore/QFileInfo>
#include <QtCore/QTextStream>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    TextEdit textEdit;
    textEdit.setWordWrapMode(QTextOption::NoWrap);
    textEdit.setUndoRedoEnabled(false);
    QString filename("../test.bin");
    QFile file(filename);
    if (!file.open(QIODevice::ReadOnly)) return 1;
    qint64 length = file.size();
    quint8 *ptr = (quint8 *)file.map(0, length);

    if (QFileInfo(filename).suffix().endsWith("bin", Qt::CaseInsensitive)) {
        QByteArray buffer;
        buffer.reserve(length * 4);
        int counter = 0;
        QTime t;
        t.start();
        for (qint64 i = 0; i < length; ++i) {
            if (!(i&0x0F)) {
                buffer.append("\n");
                counter++;
            }
            if (!(i%16)) {
                buffer.append(QString::number(i/16, 16).toUpper().rightJustified(5,'0')); // номер строки в Hex
            }
            buffer.append(" " + QString::number(*ptr++, 16).toUpper().rightJustified(2,'0')); // значение байта в Hex
        }
        qDebug("Count of lines: %d, elapsed: %d", counter, t.elapsed());
        t.start();
        textEdit.textCursor().beginEditBlock();
        textEdit.textCursor().insertText(buffer);
        textEdit.textCursor().endEditBlock();
        qDebug("Strings appended. Elapsed: %d", t.elapsed());
    }
    file.close();

    textEdit.show();
    return app.exec();
}

Хочу обратить внимание на этот кусок кода:

        qDebug("Strings appended. Elapsed: %d", t.elapsed());
    }
    file.close();

    textEdit.show();

Добавление в textEdit происходит 1 секунду, а вот после textEdit.show() начинается всё веселье.

Сообщение отредактировал SABROG - 12.12.2009, 15:20

[Litkevich Yuriy]

Программа в помощь, и тамже можно почитать всю тему - Чем большой текст показать?

и цитаты от тель:

Я пробовал QTextStream но на гигабайтах он работает гнусно медленно. Прямое чтение в несколько раз быстрее.

[BRE]

Ладно, а зачем ты тогда в свой код вставил вообще QTextStream ?

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

Я QTextStream использую потому что с ним работает быстрее, за счет дополнительной буферизации в QTextStream. Т.е. реально в QByteArray добавляется сразу готовая строка.

[&-rey]

напиши пару примеров, в которых на мобиле необходимо бинари в TextEdit совать

если выведенное скопировать в текстовый файл то его вставка даст 22 сек.

        QTextStream Stream(file);
        edit->setPlainText(Stream.readAll() + "\n");

т.е. если я захотел почитать к примеру "Война и Мир", то нужно будет подождать ...
вопрос ведь не в том как обойтись, а в том почему приходится это делать ?
вот к примеру вызов Copy из контекстного меню вставленного куска текста зависает на 22 сек, а это уже не преобразование текста а обработка существующего.

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

удивляться приходиться как раз не в делфи, хотя речь шла о С++ Builder

        TMemoryStream *Stream = new(TMemoryStream);
                         ........
        SendMessage(edit->Handle, EM_REPLACESEL, 0, (long)Stream->Memory);

те же пару строк кода, и все работает быстро, и вставка, и удаление, и копирование, и прочие возможности RichEdit
я то наивно полагал, что библиотеки разрабатываються для ускорения процесса разработки, или нет ?

Думаю при таком подходе, пользователи будут отказываться от использования такой программы еще до того как большой файл будет загружен в редактор....

и будут правы

Читай кусок файла, который помещается на экран. Понимаю, что просто использовать QTextExit не получиться, зато твой виджет будет оптимизирован для твоей задачи.

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

Программа в помощь, и тамже можно почитать всю тему - Чем большой текст показать?
и цитаты от тель:

Я пробовал QTextStream но на гигабайтах он работает гнусно медленно. Прямое чтение в несколько раз быстрее.

это читал, но не очень понял что имелось ввиду под прямым чтением. Ссылки то ведут на редактор в delphi (какая гадость), но дело в том что в Builder то как раз проблем нет.
или есть возможность совместить QT и RichEdit ? а как ?

Да и скорость потока это не главная проблема тормозов. Время парсинга у меня занимает точно такое же как и с QString - 5062мс (debug), 3313мс (release).
В релизной сборке весь текст добавляется 1 секунду в QPlainTextEdit.

вот если верить Qtime
Count of lines: 131072, elapsed: 10641
Strings appended. Elapsed: 21922
но реально получается на 15 сек больше, видимо доп затраты на отображение.

Есть ли смысл написать в support ?

[SABROG]

Есть ли смысл написать в support ?

Судя по тому, что я сегодня читал эта проблема была еще известна в 2005 году и даже в Qt3. Плюс в багтрекере уже есть подобные репорты. Но лучше написать еще раз, напомнить им о проблеме. Кстати это касается также и QTableWidget/QListWidget/QTreeWidget (*View классов тоже). И та же проблема с QPixmap, QImage (очень большую картинку хрен загрузишь, карту например). Т.е. в Qt мало чего сделали для того, чтобы интерфейс мог работать с большими объемами данных. С обычными контейнерами (QVector, QList) та же история, свои аллокаторы пишут к stl контейнерам.

SendMessage(edit->Handle, EM_REPLACESEL, 0, (long)Stream->Memory);

Это вроде как вообще к борману мало относится, тут же чистый WinAPI.

Сообщение отредактировал SABROG - 12.12.2009, 23:05

[Litkevich Yuriy]

удивляться приходиться как раз не в делфи, хотя речь шла о С++ Builder

Дельфи первичен, Билдер - вторичен. Билдер - тот же Делфи только с Си/Си++ компилятором и автоматически сгенерёными заголовочниками из исходников дельфей, все библиотеки в нём - это продук Дельфей.

Но лучше написать еще раз,

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

По теме, в Qt не реализован для текстового редактора подход Модель/представление, и ожидать от QTextEdit прыти не приходится также, как и от Q{List|Table|Tree}Widget

[&-rey]

Дельфи первичен, Билдер - вторичен. Билдер - тот же Делфи только с Си/Си++ компилятором и автоматически сгенерёными заголовочниками из исходников дельфей, все библиотеки в нём - это продук Дельфей.

это понятно, просто само слово делфи мне не нравиться. А так частенько пытаясь разобрать методы класса упирался в Pascal, причем не в код, а просто паскал класс и все тут.

Но лучше написать еще раз,в нынешнем трекере, есть возможность коментировать имеющийся рапорт, и это предпочтительный путь, вместо создания нового рапорта. Т.е. Весомость рапорта растёт.

так и сделал, присоседился к http://bugreports.qt.nokia.com/browse/QTBUG-3554
выложив видоизмененный SABROG код, уж очень он хорошо тормозит на шоу.

Т.е. в Qt мало чего сделали для того, чтобы интерфейс мог работать с большими объемами данных. С обычными контейнерами (QVector, QList) та же история, свои аллокаторы пишут к stl контейнерам.

По теме, в Qt не реализован для текстового редактора подход Модель/представление, и ожидать от QTextEdit прыти не приходится также, как и от Q{List|Table|Tree}Widget

Грустно, наверное у QT есть очень даже хорошие вещи, но хорошее как правило не помнится, а запоминаются лишь баги и проблемы.
Cпасибо, что не оставили без внимания, буду верить что QTextEdit растормозиться в следующих релизах.

PS: пошел читать про Модель/представление