diff options
author | Thomas Haller <thaller@redhat.com> | 2022-10-06 16:25:37 +0200 |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2022-10-06 17:33:48 +0200 |
commit | 06c7bc6a6bbded64b86ddf8775ba10cae96bea12 (patch) | |
tree | 734862845cf218a1a6e43aed39f9b75905493694 /src/c-stdaux/.readthedocs.yaml | |
parent | 44d99e366b7ca1eedc54e45ca269d5c2c2bc6fed (diff) | |
download | NetworkManager-06c7bc6a6bbded64b86ddf8775ba10cae96bea12.tar.gz |
glib-aux: add nm_slice_*() API to replace GSlice
glib has for a long time the GSlice API. The *only* reason to have and
use it, is the hope that it might perform better. After all, it's API
is more limited, as it doesn't support realloc() and requires the caller
to provide the memory size during free.
It's hard to accurately benchmark whether an allocator clearly performs better,
as it depends on usage and the system allocator that we compare against.
But there are some doubts whether it's faster ([1]), and it might be even
slower which totally defeats the purpose of having this.
Also, there is an long open bug to deprecate the GSlice API ([2]).
Move forward an redirect GSlice to the system allocator.
Don't completely the call patter however. For one, that would require
manual changes (or a good script). But more importantly, we already use
the GSlice API, and at the places where we do, we acknowledge to use a
more limited behavior (no realloc()) and we know the deallocation size.
Replacing all GSlice uses right away with malloc()/free() uses that
information and there is no easy way back. But the more limited API
*might* have performance benefits in the future. For example, C++
has sized allocation for this reason ([3]).
So don't drop a slice API entirely. Instead, add our own nm_slice*()
for now, which redirects to g_malloc()/g_free().
[1] https://wiki.gnome.org/Projects/GLib/GSlicePeformanceTests
[2] https://gitlab.gnome.org/GNOME/glib/-/issues/ ## 1079
[3] https://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3778.html
Diffstat (limited to 'src/c-stdaux/.readthedocs.yaml')
0 files changed, 0 insertions, 0 deletions