mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2026-01-03 15:10:14 +01:00
04d0d1bbe5
When growing a buffer by appending a previously unknown number
of elements, the often preferable strategy is growing it exponentially,
so that the amortized runtime and re-allocation costs scale linearly.
GString just always increases the buffer length to the next power of
two. That works.
I think there is value in trying to find an optimal next size. Because
while it doesn't matter in terms of asymptotic behavior, in practice
a better choice should make a difference. This is inspired by what QT
does ([1]), to take more care when growing the buffers:
- QString allocates 4 characters at a time until it reaches size 20.
- From 20 to 4084, it advances by doubling the size each time. More
precisely, it advances to the next power of two, minus 12. (Some memory
allocators perform worst when requested exact powers of two, because
they use a few bytes per block for book-keeping.)
- From 4084 on, it advances by blocks of 2048 characters (4096 bytes).
This makes sense because modern operating systems don't copy the entire
data when reallocating a buffer; the physical memory pages are simply
reordered, and only the data on the first and last pages actually needs
to be copied.
Note that a QT is talking about 12 characters, so we use 24 bytes
head room.
[1] https://doc.qt.io/qt-5/containers.html#growth-strategies
|
||
|---|---|---|
| .. | ||
| c-list | ||
| c-rbtree | ||
| c-siphash | ||
| c-stdaux | ||
| n-acd | ||
| n-dhcp4 | ||
| nm-glib-aux | ||
| nm-keyfile | ||
| nm-libnm-aux | ||
| nm-libnm-core-aux | ||
| nm-libnm-core-intern | ||
| nm-std-aux | ||
| nm-udev-aux | ||
| nm-utils | ||
| systemd | ||
| meson.build | ||
| nm-default.h | ||
| nm-meta-setting.c | ||
| nm-meta-setting.h | ||
| nm-test-libnm-utils.h | ||
| nm-test-utils-impl.c | ||
| nm-version-macros.h.in | ||