[th/gslice] replace GSlice (by NMSlice?)
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
The alternative is to drop GSlice and use malloc/free directly.
We can do a (mostly) automated conversion from GSlice to malloc/free, but not the other way around. That is, the current places that use GSlice have a more special use-case, and converting to malloc/free entirely seems to loose that information.