[Development] Question about the QDataBuffer from src/gui/painting
Marc Mutz
marc.mutz at kdab.com
Mon Oct 26 10:12:17 CET 2015
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
More information about the Development
mailing list