4 ms·

Hi there, great work writing oat++. I am the author of Passenger (https://www.phusionpassenger.com https://www.phusionpassenger.com), an application server that

Hi there, great work writing oat++. I am the author of Passenger (https://www.phusionpassenger.com https://www.phusionpassenger.com), an application server that powers 650.000 companies and sites world-wide such as Apple, Pixar, Juniper, etc. Passenger is mostly written in C++ and like you, performance is a priority for us. I've done a fast code review, and I thought I'd share some of my findings with you. These are based on my experience with writing high-performance servers. You can read about some of my experience in these blog posts: https://www.rubyraptor.org/how-we-made-raptor-up-to-4x-faster-than-unicorn-and-up-to-2x-faster-than-puma-torquebox/ https://www.rubyraptor.org/how-we-made-raptor-up-to-4x-faste... Hopefully you can use my feedback to make oat++ even faster and better. Code review here: https://github.com/oatpp/oatpp/issues/15 https://github.com/oatpp/oatpp/issues/15 I've covered: - Pools and contention - Shared_ptr and atomics everywhere - List vs vector - Zero-copy architecture - SpinLock everywhere - New does not return nullptr? - More documentation - More tests

lganzzzo 8y ago
Thanks, this is a really good code-review! I appreciate this!
M_Bakhtiari 8y ago
Good point on the shared_pointers. What's your opinion on using Ravenbrook MPS pools and not deal with refcounts at all?
- lganzzzo 8y ago
  Memory management, and pools. 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 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.
- FooBarWidget 8y ago
  I have no experience with Ravenbrook MPS. But from the documentation it appears to contain both tracing garbage collectors (automatic memory management) as well as manual memory managers. Not dealing with refcounts implies using a tracing garbage collector. There is a wide range of literature out there about such a comparison, but in general I cannot compare the two at all because of the vast fundamental differences.
joshstrange 8y ago
I would just like to say that as someone who has never used Passenger, never used Oat++, and hopes to god he never has to write a line of C++ again this comment (and the linked code review) really warmed my heart. Not only is it a positive/helpful comment in a world with so much focus on tearing down and picking apart but it's all of that from the author of a competing framework. You go even further to review the code and suggest ways to make your "competitor"'s (I use the word lightly in this context but "framework wars" often take on an almost religious zeal) product better. I will probably never use either of your frameworks directly but I'd like to just say thank you FooBarWidget for this, it made me smile.

lganzzzo 8y ago

Thanks, this is a really good code-review! I appreciate this!

M_Bakhtiari 8y ago

Good point on the shared_pointers. What's your opinion on using Ravenbrook MPS pools and not deal with refcounts at all?

lganzzzo 8y ago
Memory management, and pools. 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 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.
FooBarWidget 8y ago
I have no experience with Ravenbrook MPS. But from the documentation it appears to contain both tracing garbage collectors (automatic memory management) as well as manual memory managers. Not dealing with refcounts implies using a tracing garbage collector. There is a wide range of literature out there about such a comparison, but in general I cannot compare the two at all because of the vast fundamental differences.

joshstrange 8y ago

I would just like to say that as someone who has never used Passenger, never used Oat++, and hopes to god he never has to write a line of C++ again this comment (and the linked code review) really warmed my heart. Not only is it a positive/helpful comment in a world with so much focus on tearing down and picking apart but it's all of that from the author of a competing framework. You go even further to review the code and suggest ways to make your "competitor"'s (I use the word lightly in this context but "framework wars" often take on an almost religious zeal) product better. I will probably never use either of your frameworks directly but I'd like to just say thank you FooBarWidget for this, it made me smile.