Memory management is definitely super important and has big impact on the performance. Also there is a memory fragmentation issue that you should keep in mind building server apps.
Solving this problems is time consuming and you need to do a lot of experiments in order to tune all this system.
So if there is a robust time-proved solution for solving this problems it is definitely worth of considering.
shared_ptr and refcounts - actually it is a compromise (like any other solution).
On the one hand you could avoid refcounts, atomics etc. On the other hand you have
a framework for the end user. And user may be not so familiar in depth of your framework's thread management and concurrent access to some shared objects.
Also end-user may decide to bring in some other library which for example uses shared_ptr. And what user should do if he has to share some object among std::shared_ptr and your own custom shared-ptr:)?
This is the reason I decided to go with std::shared_ptr (with it's atomic refcounter) as I mentioned in the code-review in the response https://github.com/oatpp/oatpp/issues/15
Now about Ravenbrook MPS pools in particular:
It seems to be a robust time-proved solution which may help you to avoid a lot of pain.
As for oatpp - oatpp claims to be zero-dependency at the moment. So no external dependencies are considered at the moment.
This may be changed at some moment in the future but not for now.
Memory management is definitely super important and has big impact on the performance. Also there is a memory fragmentation issue that you should keep in mind building server apps. Solving this problems is time consuming and you need to do a lot of experiments in order to tune all this system. So if there is a robust time-proved solution for solving this problems it is definitely worth of considering.
shared_ptr and refcounts - actually it is a compromise (like any other solution). On the one hand you could avoid refcounts, atomics etc. On the other hand you have a framework for the end user. And user may be not so familiar in depth of your framework's thread management and concurrent access to some shared objects.
Also end-user may decide to bring in some other library which for example uses shared_ptr. And what user should do if he has to share some object among std::shared_ptr and your own custom shared-ptr:)?
This is the reason I decided to go with std::shared_ptr (with it's atomic refcounter) as I mentioned in the code-review in the response https://github.com/oatpp/oatpp/issues/15
Now about Ravenbrook MPS pools in particular: It seems to be a robust time-proved solution which may help you to avoid a lot of pain. As for oatpp - oatpp claims to be zero-dependency at the moment. So no external dependencies are considered at the moment. This may be changed at some moment in the future but not for now.