Thomas Haller 04d0d1bbe5 shared: add nm_utils_get_next_realloc_size() helper ... 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		2020-04-03 11:31:12 +02:00
..
meson.build	license: Add license using SPDX identifiers to meson build files	2020-02-17 13:16:57 +01:00
test-shared-general.c	shared: add nm_utils_get_next_realloc_size() helper	2020-04-03 11:31:12 +02:00