[Development] Dropping QT_NO_STL (was: The future of QtAlgorithms)

Thiago Macieira thiago.macieira at intel.com
Tue Jan 31 12:12:01 CET 2012


On Tuesday, 31 de January de 2012 11.38.05, André Pönitz wrote:
> > I'd like our containers to be good enough for that, to be honest. And
> > avoid
> > subtle mistakes if the behaviour differs.
> 
> The problem is that QVector is _not_ "good enough" for some cases, mostly
> due to the sharing overhead.
> 
> Using std::vector in  _p.h or .cpp where it makes sense seems perfectly fine
> to me, (as would tackling the sharing problem)

Tackling the sharing problem is something that João wanted to do.

> > Just avoid "template bloat": out-of-line copies of identical code because
> > the compiler can't figure out two functions do the same. It's hard to
> > measure.

> But it _is_ measurable, and when you do it you'll come to the result that
> straightforward QVector using code (i.e. using at() or even operator[]
> instead of .data() plus pointer[index]) expands to significantly more code
> than std::vector. An awful lot of std::vector code expands to a handful
> instructions while QVector access has all kind of indirections and
> conditional execution.

One of the conditionals must be the check for the refcount. Having removed the 
volatile now, one would expect that the compiler knows it hasn't changed 
across the two calls.

Still, doing benchmarks now is pointless since there's a major rewrite pending 
from João's "containers" branch. Once that is in, I'd like to spend some time 
inspecting the code generated and see how to improve it. I'll repeat your 
tests once that is in.

> So QVector has an advantage when it is copied, but loses by
> a factor of almost two in local access in this case.
> 
> I argue that local access happens more often than copying,
> so QVector is optimizing for the wrong use case.

We need to fix that then.

> Of course you can tweak the code at get better results, at the expense
> of readability and convenience, and not all access pattern are _that_
> bad. But the bottom line stays.

Indeed. Reading STL container code is *not* fun. Not only is the coding 
convention ugly by our standards, it goes all over the place.

> If you/we want to have a "good enough" replacement with sane syntax
> and all the Qt container convenience, drop the sharing from QVector.
> 
> As the change would be essentially source compatible we do have
> the chance to fix it in Qt 5.

See above.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120131/fde8f558/attachment.sig>


More information about the Development mailing list