[Development] Question about QCoreApplicationData::*_libpaths

Marc Mutz marc.mutz at kdab.com
Wed Jan 20 18:56:32 CET 2016


On Wednesday 20 January 2016 16:03:00 Jędrzej Nowacki wrote:
> On Tuesday 19 of January 2016 13:51:56 Marc Mutz wrote:
> > On Tuesday 19 January 2016 11:15:43 Milian Wolff wrote:
> > > On Dienstag, 19. Januar 2016 11:51:42 CET Marc Mutz wrote:
> > > > I missed one:
> > > > 
> > > > On Monday 18 January 2016 23:43:37 Marc Mutz wrote:
> > > > >     #include <QVector>
> > > > >     #include <string>
> > > > >     
> > > > >     int main() {
> > > > >     
> > > > >         QVector<QByteArray> l;
> > > > >         int oldC = l.capacity();
> > > > >         for (int i = 0; i < 10000000; ++i) {
> > > > >         
> > > > >             char buf[std::numeric_limits<int>::digits + 1];
> > > > >             sprintf(buf, "%d", i);
> > > > >             l.push_back(buf);
> > > > >             int newC = l.capacity();
> > > > >             if (newC != oldC)
> > > > >             
> > > > >                 qDebug("%d", newC);
> > > > >             
> > > > >             oldC = newC;
> > > > >         
> > > > >         }
> > > > >     
> > > > >     }
> > > > >     
> > > > >     $ time ./test
> > > > >     <snip>
> > > > >     real    0m1.769s
> > > > >     user    0m1.572s
> > > > >     sys     0m0.192s
> > > > 
> > > > Same with std::vector<QByteArray>:
> > > > 
> > > > real    0m1.776s
> > > > user    0m1.616s
> > > > sys     0m0.156s
> > > > 
> > > > > best of three runs, core i7-2720QM, GCC 5.3
> > > > 
> > > > Ditto.
> > > > 
> > > > So... is realloc actually the optimisation everyone (incl. me)
> > > > expected it to be?
> > > 
> > > Did you run it through a profiler? Where is the time actually spent?
> > 
> > No. It's not the IO, though. Removing the qDebug() and capacity tracking,
> > it performs the same, within error margins.
> 
> Hi,
> 
>   I can not reproduce the numbers on gcc version 5.3.1 20151219 (Debian
> 5.3.1-4). But there is a bug in the benchmark, std::vector and QVector have
> different grow model, at least I do not see the same count of qDebug
> messages. In addition I think the benchmark may be affected by heap
> allocation executed on each l.push_back.

That's weird. qAllocMore() uses 2^N-const, const > 0, in my tests, while 
std::vector uses 2^N. I specifically used a count that is a power of 10 so that 
this difference would not cause a different number of reallocations:

1
3
7
15
31
63
127
255
511
1023
2047
4095
8191
16383
32767
65535
131071
262143
524287
1048575
2097151
4194303
8388607
16777215

(for QVector with a movable std::string)

1
2
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
524288
1048576
2097152
4194304
8388608
16777216

(for std::vector)

>  The feature is also used in QVariant which tries to avoid allocations.
> That was confirmed as important optimization.

Well, halving the time spent on reallocation is an optimisation, I guess. It's 
just that that particular problem is easily worked around with reserve(). 
QVariant is a different matter, indeed.

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts



More information about the Development mailing list