> On 26 Oct 2015, at 10:12, Marc Mutz <marc.m...@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.m...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development