Improving reproc performance

[coder137]

This is in line with my follow up question in #56

I ran some benchmarks using the Google Benchmark framework

static void BM_ReprocBlockingAPI(benchmark::State &state)
{
  const char *sargv[] = { "gcc", "../main.c", NULL };
  int status = -1;
  std::error_code ec;
  reproc::options options;
  options.nonblocking = false;
  options.redirect.parent = true;
  options.stop = {
    { reproc::stop::wait, reproc::infinite },
  };
  for (auto _ : state) {
    std::tie(status, ec) = reproc::run(sargv, options);
    assert(status == 0);
  }
}

static void BM_SystemAPI(benchmark::State &state)
{
  const char sargv[] = "gcc ../main.c";
  int status = -1;
  for (auto _ : state) {
    status = system(sargv);
    assert(status == 0);
  }
}

BENCHMARK(BM_ReprocBlockingAPI);
BENCHMARK(BM_SystemAPI);

This was the output I got

Running D:\CustomBuilds\reproc\example\build\benchmark_system.exe
Run on (12 X 2592 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x6)
  L1 Instruction 32 KiB (x6)
  L2 Unified 256 KiB (x6)
  L3 Unified 12288 KiB (x1)
---------------------------------------------------------------
Benchmark                     Time             CPU   Iterations
---------------------------------------------------------------
BM_ReprocBlockingAPI  108173902 ns      4375000 ns          100
BM_SystemAPI          112368309 ns       781250 ns          100

The reason why I have run reproc is blocking mode is to simulate the system C API. Later to improve throughput I can use Threads to speed up the overall work done.

Question

The Time taken by the reproc blocking API is lesser when measured over 100 iterations, However, the CPU time is much much higher.

• What is the reason for this and would there be any performance impact?
• Are there ways to further improve the performance? Running in nonblocking mode with reproc would be similar to using threads with the system C API as well. Any other tips/tricks would be very helpful.

[DaanDeMeyer]

Well, I'm not sure of the internals of system, but reproc could be doing strictly more work than system is with all it's added features so it wouldn't surprise me that in a micro benchmark it might be slower.

Unfortunately, I've never done benchmarking of reproc's performance at this level as performance has never really been a goal of reproc. If you do some profiling and make PRs that improve performance without severely complicating the code, I wouldn't mind reviewing them. I don't really have the time (or motivation) to do this myself though.