[Development] Important recent changes in QList/QString/QByteArray

[Andrei Golubev]

Should I expect to do a reserve call with a *smaller* value than my
current size is before removing elements from
a container, in order to set a "target size"? For any standard
container, such a reserve is a complete noop because
it can't be responded to by shrinking a capacity lower than the size,
but with QList it apparently records a preferred size?
No. If the value passed to reserve is smaller than capacity, we do not shrink*.
For any passed value, we set a specific flag that the capacity is reserved. There is no notion of "target size" and "target capacity" is out of scope of the container (this is something that the user knows about).
Instead, having the flag in place, we can decide whether allocation should take place or not. When allocation is not obligatory and the capacity reservation flag is set, we do not reallocate but instead do "something else": in case of erase - just remove elements, in case of prepend - move data around (if necessary).
The flag is a mere part of QCC's state.

* let aside the case when QCC is implicitly shared

--
Best Regards,
Andrei
________________________________
From: Ville Voutilainen <ville.voutilainen at gmail.com>
Sent: Thursday, September 10, 2020 3:43 PM
To: Andrei Golubev <andrei.golubev at qt.io>
Cc: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Important recent changes in QList/QString/QByteArray

On Thu, 10 Sep 2020 at 11:46, Andrei Golubev <andrei.golubev at qt.io> wrote:
>
> That's interesting. So the container remembers what sort of a reserve
> request I made on it, and uses
> that as the preferred size whenever the element count of the container changes?
>
> Yes. Calling reserve typically means that you do not want to have extra reallocations while updating the container's content (instead you allocate sufficient space upfront). In case of QList, we make sure there are no reallocations happening unless absolutely necessary, e.g. appending 1 element when size == capacity would allocate bigger memory chunk - reservation is a hint, but not an obligation. Consequently, QList's shrinking erase also does not shrink when capacity is reserved.

Well, yeah - calling reserve before growing a container avoids extra
allocations. Calling reserve before removing elements
doesn't have such a "typical" effect.

Should I expect to do a reserve call with a *smaller* value than my
current size is before removing elements from
a container, in order to set a "target size"? For any standard
container, such a reserve is a complete noop because
it can't be responded to by shrinking a capacity lower than the size,
but with QList it apparently records a preferred size?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200910/70de7455/attachment-0001.html>