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

[Marc Mutz]

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.

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).

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.

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