Тормоза в Qt IO

[BRE]

Не может компилятор такое кушать, ибо размер массива во время компиляции не определён, следовательно неизвестно сколько откусывать стека. Специально для этого придумали QVarLengthArray.

Может, это расширение GCC, попробуй сам.
Про визуалы не скажу не знаю.

[Dendy]

Что пробовать то? Покажите минимальный рабочий пример.

[BRE]

Что пробовать то? Покажите минимальный рабочий пример.

Код

C++ (Qt)
#include <iostream>
 
void func( int sz )
{
        char arr[ sz ];
 
        for( int i = 0; i < sz; ++i )
                arr[ i ] = (char)i;
 
        for( int i = 0; i < sz; ++i )
                std::cout << (int)arr[ i ] << std::endl;
}
 
int main( int argc, char *argv[] )
{
        func( 10 );
        func( 20 );
}
 

и

g++ a.cpp

[Dendy]

Действительно, откусывает стек динамически. Проверил в MinGW/GCC4.4.0. А как это соотносится со стандартом?

[BRE]

Действительно, откусывает стек динамически. Проверил в MinGW/GCC4.4.0. А как это соотносится со стандартом?

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Variable-Length.html#Variable-Length

[Dendy]

Спасибо. Другими словами - этого нет в стандарте. Собственно здесь MSVC ведёт себя корректно. Даже в документации по Qt есть замечание:

The C++ language doesn't support variable-length arrays on the stack. For example, the following code won't compile:

 int myfunc(int n)
 {
     int table[n + 1];  // WRONG
     ...
     return table[n];
 }

Я бы рекомендовал избегать таких конструкций, особенно в кроссплатформенном коде. Тем более, что таким образом стек может закончиться куда быстрее. К примеру попытка создать динамический массив на 2Мб мгновенно обернулась крешем приложения.

[ilot]

Невооружённым глазом видно утечку в readString(). Пользуйтесь для этих случаев QVarLengthArray.

можно еще использовать постоянный буфер. Буфер создается один раз, следовательно не нужно при каждом вызове выделять и освобождать память:

Код:

const size_t buffSize = 100;
//...
//где-то при конструировании "объекта-читалки"
unsigned char* buff = new unsigned char[buffSize];

//функция чтения строки
inline QString readString(QFile& f, int count)
{
	memset(buff, 0, buffSize);
	f.read(buff, count);
	return QString(buff).trimmed();
}
//по окончанию чтения файла не забыть зачистку
delete []buff;

Мапится боюсь, размеры могут быть до 10Gb.

Судя по описанию функции

Код:

uchar * QFile::map ( qint64 offset, qint64 size, MemoryMapFlags flags = NoOptions )

отображать файл в память можно кусками, поэтому эту возможность тоже следует рассмотреть

Как справедливо заметил Константин, маленькие утилитарные функции нужно сделать подставляемыми.

По технике: чтобы избежать опечаток и облегчить чтение/понимание кода, "магические" числа лучше заменить на целочисленные константы (const int ...).

[ритт]

не-не-не, нафик мемсет...

Код

C++ (Qt)
static inline QString readString(QIODevice *f, int count, uchar* buff)
{
	int len = f->read(buff, count);
	return QString(buff, len).trimmed();
}
 

[romank]

Да и зачем динамическое unsigned char* buff = new unsigned char[buffSize], если размер буфера заранее известен. QString::QString ( const QChar * unicode, int size ) я так понимаю уникод онли, не помогло. Внес все коррективы, видимо компилятор и так достаточно умен, прирост ноль. Трудно ловить точное время с IO.

[ритт]

ах, ну, да
return QString::fromUtf8(buff, len).trimmed();

[vaprele07]

не стоит городить велосипед: QBuffer + QFile::map

[ритт]

и не может быть чтобы приросту было ноль...

смотрю далее:
вместо read вполне можно пропускать по seek;
while (file.pos() != file.size()) - довольно неоптимально, лучше заменить на while (!file.atEnd()) ;
ну, и как уже было сказано ранее, сотня чтений по 4 байта (инт) затратнее одного чтения четырёхсот байт ->
читай документацию по QBuffer (затем будешь читать в байтаррэй н байт, где н - размер твоего блока, завернёшь байтаррэй в буффер и подставишь буффер вместо файла (для этого мы заменили QFile на QIODevice ранее))

[ilot]

Да и зачем динамическое unsigned char* buff = new unsigned char[buffSize], если размер буфера заранее известен.

Сам бы я определил отдельный класс для обработки файла, а все эти функции сделал его методами. Отсюда логично, чтобы память для буфера динамически выделялась в его конструкторе и освобождалась в деструкторе, а не заранее в статической области памяти. Собственно только из этих соображений...

не стоит городить велосипед: QBuffer + QFile::map

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

[vaprele07]

Мапируем или весь файл или нужную область (100 метров или 1гб) "QByteArray::fromRawData" в QBuffer и подставляем в проблемный код.

Хотя возможно я не понял задачу   

[xokc]

Мапируем или весь файл или нужную область (100 метров или 1гб) "QByteArray::fromRawData" в QBuffer и подставляем в проблемный код.

Хотя возможно я не понял задачу   

+100. Мапить можно не весь файл, а только часть его (чем больше - тем лучше) - на винде будет в разы быстрее работать.