[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