[Development] Question about the QDataBuffer from src/gui/painting

[Gunnar Sletta]

> On 26 Oct 2015, at 10:12, Marc Mutz <marc.mutz at kdab.com> wrote:
> 
> On Monday 26 October 2015 08:20:38 Gunnar Sletta wrote:
>> The purpose of QDataBuffer is to provide a managed pool of memory that can
>> grow, but does not shrink unless shrunk explicitly. QVector is unusable
>> for this purpose as a resize/clear/append would cause a lot of
>> reallocations for the places where QDataBuffer is used. 
> 
> QDataBuffer uses realloc(), which of course std::vector cannot. With a 
> geometric growth strategy, this doesn't matter much, and most types held in 
> QDataBuffer are PODs (maybe not in C++98, but in C++11), but if it turns out 
> that it does matter, then fixing QVector to not shed excess capacity at the 
> first opportunity would be the right thing to do.

I can't remember why we used realloc. This class was written as part of the paint system in 4.0, so it is a long time ago. I agree that it doesn't look like it is needed.

> That said, neither QVector nor std::vector will match the performance of 
> QDataBuffer, which declines to care about such basic things as copying and safe 
> appends from an already-existing element or Ts which aren't Q_PRIMITIVE_TYPE 
> (it should assert that, btw).

True, it was never intended to be generic copyable container, just a managed memory pool to help with reallocations. 

> But either (QVector w/fixed capacity management or std::vector) should be fast 
> enough. Surely, the ported code will be faster, because stuff like calling 
> points() over and over in QPathSegments::mergePoints() will be found and fixed.

I don't think changing QVector is the right thing. That is bound to have side effects elsewhere, so I don't like that. std::vector wasn't an option back when the class was written, but it that was a long time ago. Looks more sensible now.

Also, given the purpose of this class, then using QDataBuffer as an on-the-stack member in a function (like in mergePoints()) will pretty much always be wrong. There is no point in using a pool when it is discarded after a single use, after all. 


> 
> Thanks,
> Marc
> 
> -- 
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development