Ad-filter loading and QRegExp performance

[Ingo Klöcker]

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.  I am not sure of the best way to do that.
> >
> > A 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.

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

for ( run = 0; run < maxRuns; run++ ) {
  start timer
  {
    CONTAINER<simple_struct_with_two_float_entries> l;
    for ( i = 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 
times slower than QVector. In release mode it was just 10 times slower. 
(FWIW, this is on Windows.) The slowness of QList seems to be caused by 
the fact that deleting hundred thousands objects takes a lot of time. 
So much for "That means one extra malloc()," It means just one extra 
malloc() per list.append(), but it means list.size()+1 free() when the 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-optimize/attachments/20070203/6e338020/attachment.pgp