Performance code review about oatpp

[Joshua-Ashton]

But new does not return nullptr, it throws an exception.

This is "standard" correct, but not real world correct -- not everyone uses C++ exceptions (at the compiler level), therefore it could be nullptr. It's better to be safe than sorry.

[lganzzzo]

@FooBarWidget
Thank you so much for your code review, and your time!
It is very valuable input!

More documentation is really an issue and I am working on it right now.

Here is a brief answer and I will get back to you with the full answer a bit later:

What I do in Passenger is using smart pointers that do not use atomic counters.

I used to have custom smart-pointers in oat++ before but gave-up this idea in advantage for compatibility. So end-user could easier work with the framework.
Also performance impact was really very very small

I do not understand what ChunkedBuffer is supposed to be and how that's different from FifoBuffer

• ChunkedBuffer is basically a chain of chunks. It provides possibility to grow buffer without copying the memory. Also chunks are pool allocated in order to reduce memory fragmentation.
• FifoBuffer is for the future feature and not used currently.

On the conceptual level, I have no idea how the coroutine stuff works and is supposed to be used. I have also no idea what concurrency model you are using. Is it one-client-per-thread?

Currently there are two concurrency models implemented:

• Multithreaded (1 connection - 1 thread)
• Async (fixed number of threads for all connections)
  more is here https://oatpp.io/docs/simple-vs-async

Coroutines and Async:
Are used in the async model together with non-blocking IO (non-blocking sockets).
Coroutines are served by oatpp::async::Processor.

These are stateless coroutines. On each iteration coroutine returns Action which is basically an action of what to do next. Action provides possibility for additional prioritization like put to "waiting queue" coroutine which waits for IO.

You may treat this approach like app-level implementation of epoll/kqueue. But this gives additional space for experiments and it makes end-user API a bit easier.

Did you manage to run some performance tests on your machine?

Thank you for the code-review once again!

[FooBarWidget]

I added some edits. In particular, I added feedback about zero-copy.

Also performance impact was really very very small

In my experience with Passenger, such impact was indeed small on its own. But I optimized Passenger by solving a thousand paper cuts — optimizing 1% here, 0.5% there, 1.2% there, etc. They all added up.

[jcelerier]

This is "standard" correct, but not real world correct -- not everyone uses C++ exceptions (at the compiler level), therefore it could be nullptr

I just tried with both GCC and clang : adding -fno-exceptions still makes new throw an exception so I guess the number of cases where new would return nullptr in real-world code is very very close from zero.

#include <cstdio>

int main()
{
  constexpr auto max = 100000000000;
  auto blob = new char[max];

  // the following added to ensure that the compiler does not 
  // optimize the allocation if it's not used
  auto f = fopen("/dev/null", "w");
  fwrite(blob, 1, max, f);
}

->

$ g++ -O3 foo.cpp -fno-exceptions 
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

the generated assembly does not even change : https://gcc.godbolt.org/z/YCrwAX - looking how it's done in libc++ you would have to recompile it with an additional define for instance, and how many people are actually able to recompile their stdlib ?

[Joshua-Ashton]

I was mainly referring to MSVC (not sure if this is the same behaviour as GCC now, it never used to be) and people who may override new with their own memory stuff in future.

[FooBarWidget]

My point w.r.t. operator new and exceptions is that the calling code only checks for nullptr, but does not attempt to catch an exception.