Custom allocator experiment

[darsvador]

A basic implementation of #223

The custom allocator test is in test/main.cpp.

[skypjack]

@stefanofiorentino what do you think about this? 🙂

[stefanofiorentino]

I think allocation is always an interesting topic. Will review this asap

[stefanofiorentino]

Frankly, I'm a bit confused about what's the goal over here. @DuckVador can you briefly show a "real" use case of this? The test/main.cpp doesn't let me think of a useful use case, sorry for this.

[darsvador]

@stefanofiorentino libuv doc gives a very brief introduction with custom allocation。

As an example, applications with custom allocation schemes such as using freelists, allocation pools or slab based allocators may decide to use a different size which matches the memory chunks they already have.

I think a general technique for memory allocation optimization is allocation pools. This answer give a C implementation of the original libuv API.

[stefanofiorentino]

Got it, as me, you don't like memory increasing and decreasing over time. Now, I'm just wondering if we can arrange a better solution to assign the allocator at runtime (i.e. I don't love the setAllocator call). Let me think about this new issue while commuting this evening.

[skypjack]

As far as I can see, we can assign allocators on a per-handle basis at runtime, on a per-type basis at runtime or on a per-type basis at compile-time. Probably also on a per-handle basis at compile-time, even though this will literally duplicate the number of symbols.

[stefanofiorentino]

@DuckVador I got a further question for you. Are you ok with just the custom allocation for read buffer, or your final target is to have a memory pool for every allocation in the lib? This question arose to me highlighting how compliant we have to stay to the STL stuff (and the trend to be as much as possible compile-time).

[darsvador]

@stefanofiorentino For me, my goal is to customize the read buffer, a custom allocator at runtime (like OpenCV), or at compile time (like STL) is acceptable. But I do not recommend to force user to implement std::allocator directly which is too complex for our case.

[stefanofiorentino]

As I would stick to the standard stuff as much as possible, I have to pass back the baton. @skypjack what do you think? Would you accept a refinement of this proposal or you would like to introduce something different. Waiting for std::pmr is not an option, I sadly think.

[skypjack]

Unfortunately, std::pmr is literally unusable in the vast majority of cases, especially in those where you would use libuv. Personally, I think a compile-time setting can be easier to work with in the long term rather than a per-handle solution like this one. Though, I'm open to feedback.

[darsvador]

Waiting for a compile-time version of custom allocator. Close this PR. :)

[stefanofiorentino]

Let's continue investigating within next few weeks as it can be useful for several application.