Re: Ad-filter loading and QRegExp performance

--nextPart1405670.03hmKQmIXI
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 01 February 2007 14:46, Thiago Macieira wrote:
> Lubos Lunak wrote:
> >> Initially I tried replacing QVector<QRegExp> with
> >> QVector<QRegExp*> instead, but I realised that KHTMLSettings needs
> >> to be copied, and so these pointers would need to be shared
> >> somehow. =A0I am not sure of the best way to do that.
> >
> >=A0A simpler way should be storing also QVector<QString>, initially
> > have QVector<QRegExp> empty and fill it only when it's needed for
> > the first time.
>
> Note that QVector stores the elements themselves in the vector. Every
> time it grows, it must copy the elements to the new array. Tulip
> classes are somewhat clever about their growth strategy, but if you
> know beforehand how many items you'll need, you can tell it. It
> should help a lot.
>
> Also note that QList does not have this problem. For a complex type
> like QRegExp, QList does not store the elements themselves in the
> vector. It stores a pointer to them. That means one extra malloc(),
> but no object is copied during resizing.

=46WIW, at work I noticed that using QList for lists with millions of=20
entries (the entries are 3D-coordinates) is way slower than QVector. In=20
particular, the destruction of the QList took ages while the=20
destruction of a QVector doesn't take any time. My test did basically=20
the following for QList and QVector:

for ( run =3D 0; run < maxRuns; run++ ) {
  start timer
  {
    CONTAINER<simple_struct_with_two_float_entries> l;
    for ( i =3D 0; i < numElements; i++ ) {
      l.append( simple_struct_with_two_float_entries( i, i ) );
    }
    print timer before destruction
  }
  print timer after destruction
}

In debug mode and for numElements in the hundred thousands QList was 100=20
times slower than QVector. In release mode it was just 10 times slower.=20
(FWIW, this is on Windows.) The slowness of QList seems to be caused by=20
the fact that deleting hundred thousands objects takes a lot of time.=20
So much for "That means one extra malloc()," It means just one extra=20
malloc() per list.append(), but it means list.size()+1 free() when the=20
list is destroyed (compared to 1 free() in the case of QVector).

But for a few hundred QStrings this is of course irrelevant.

Regards,
Ingo

--nextPart1405670.03hmKQmIXI
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBFw8e+GnR+RTDgudgRAtjrAKDFWoMpzgL3VdjgbK6fNVhcXC4FsgCghitQ
fpQjQNlCiwjTBPT/cft1aXk=
=Slw/
-----END PGP SIGNATURE-----

--nextPart1405670.03hmKQmIXI--