[Qt-interest] performance issue

João Abecasis joao at trolltech.com
Mon Jan 4 19:19:34 CET 2010


Hi Paul,

Paul Floyd wrote:
> I've just been doing a few tests on a small app that mostly does regex parsing
> of a text file (56Mbyte). Times were as follows

Would it be possible to look at the source code and sample data from 
your tests?

> Qt 4.1.4, GCC 3.4.3 22.6 sec
> Qt 4.6.0, GCC 4.0.2 33.7 sec
> Qt 4.6.0, Sun Studio 12u1 28.3 sec
>
> all on Solaris 10 on SPARC.
>
> I'm not surprised to see the difference between the 2nd and 3rd results. It's
> the difference between the 1st and 2nd that I didn't expect.
>
> My observations after profiling:
> QIODevice::readline time increased by about 5.7 seconds
> QRegExp::indexIn increased by about 1.6 seconds
> (both inclusive times)
>
> Heading the exclusive times league increases
> take_deferred_signal (libc) increased by about 2.7 sec
> lseek64 (libc) increased by about increased by about 2.1 sec.
>
> take_deferred_signal seems to be called mainly from malloc (and realloc in case
> 3).
> lseek64: case 2, QIODevice::atEnd; case 3, called by ftello64 and fseeko64.

Is QIODevice::atEnd being called from inside Qt or from the test app?

Currently, in Qt 4.6.0, calling atEnd on a QFile requires stat'ing the 
filesystem. If you could avoid calling this function yourself you should 
see improvements in performance.

Specifically, loops such as,

     QIODevice &device /* = getDevice() */;
     QByteArray line;
     while (!device.atEnd()) {
         line = device.readLine();
         // do something
     }

Can be changed to,

     while (line = device.readLine(), !line.isEmpty()) {
         // do something
     }

The line-break is included on "empty" lines, so that isEmpty will return 
false; line will be empty when the end of device is reached and there's 
nothing left to read.

> Any comments on this?

I would be interested in looking at your benchmarks to identify hotspots 
inside Qt that you may be hitting.

Btw, did you try opening the device in Unbuffered mode as well? From 
inspecting the code, it seems that Qt may be doing double-buffering 
otherwise (once by Qt itself and again by using standard streams) :-/ -- 
I should fix this...

> I might do some more tests, but it gets a bit tedious building lots of different
> Qt versions.

You should be able to compile and install different Qt versions to 
different directories (i.e. with the -prefix option to configure), so 
you don't have to recompile all the time. You can then pick the 
different versions of qmake and Qt libraries by setting PATH and 
LD_LIBRARY_PATH environment variables accordingly.

Cheers,


João



More information about the Qt-interest-old mailing list