Large overhead compared to ProcessBuilder

[antonio-rodriges]

Hi,

NuProcess has been designed to reduce process startup overhead. However, using NuProcess I observe significant increase of startup overhead (about 3x times).

I have used Zt-Exec before which is based on ProcessBuilder

String output =
        new ProcessExecutor()
                .command(params)
                .readOutput(true)
                .timeout(1, TimeUnit.MINUTES)
                .exitValue(0)
                .directory(new File(inputFilePath))
                .execute()
                .outputUTF8();

Now I switched to NuProcess and observe increased overhead:

NuProcessBuilder pb = new NuProcessBuilder(params); pb.setCwd(Paths.get(inputFilePath));

ProcessHandler handler = new ProcessHandler();
pb.setProcessListener(handler);

NuProcess process = pb.start();
process.waitFor(1, TimeUnit.MINUTES); 

I tested on Windows 10 and Linux Ubuntu

Observations:

• large overhead occurs during the first startup of an external tool
• zt-exec is faster than NuProcess for about 0.3 sec for consequtive startups

Any suggestions?

[brettwooldridge]

I haven't benchmarked single process creation, but 0.3 seconds overhead for startup is surprising.

For example, one of the unit tests runs batches of 100 processes, twenty times (so, 2000 total), and pumps 600KB through each process (read and write), and does so in several seconds total; where several is single digit on my computer.

Having said that, for a single process, you are unlikely to see a speed advantage. NuProcess is specifically designed for low memory footprint when running lots of processes; where lots is 10-hundreds (or even thousands).

But still, NuProcess does have about a 20% speed advantage when the process count passes the processor core count by a factor of 2 or more.

Finally, the native Process code is er... native ... and therefore enjoys some advantage there. So, if you intend to benchmark NuProcess you need to make sure you are using the server JVM (-server) get its core execution code paths over the JIT compilation threshold; 10000 executions of the same code path.

The gold standard for benchmarking on the JVM is jmh, which takes care of JVM warm-up and has mechanisms to avoid invalid optimizations that throw off accurate measurements. I am experienced with jmh so If I have time I'll try to put together a benchmark. You if course are also welcome to contribute one.

[antonio-rodriges]

Finally, the native Process code is er... native ... and therefore enjoys some advantage there. So, if you intend to benchmark NuProcess you need to make sure you are using the server JVM (-server) get its code execution code paths over the JIT compilation threshold; 10000 execution of the same code path.

No, I did not mean to benchmark NuProcess, I just wanted to try it whether it will accelerate my software. The github page tells that NuProcess is faster because it uses vfork instead of fork but in practice I do not observe speedup.

I see you mainly use "cat". Have you tried smth more heavyweight? I wonder why I should warm up JVM for native code? It would be good if you could share your experience with jmh.

On Windows NuProcess exhibits even larger startup overheads - 10 seconds startup time in contrast to Zt-Exec with only 4-6 seconds (which uses ProcessBuilder).

2017-01-28 11:49 GMT+03:00 Brett Wooldridge notifications@github.com:

I haven't benchmarked single process creation, but 0.3 seconds overhead for startup is surprising.

For example, one of the unit tests runs batches of 100 processes, twenty times (so, 2000 total), and pumps 600KB through each process (read and write), and does so in several seconds total; where several is single digit on my computer.

Having said that, for a single process, you are unlikely to see a speed advantage. NuProcess is specifically designed for low memory footprint when running lots of processes; where lots is 10-hundreds (or even thousands).

But still, NuProcess does have about a 20% speed advantage when the process count passes the processor core count by a factor of 2 or more.

The gold standard for benchmarking on the JVM is jmh, which takes care of JVM warm-up and has mechanisms to avoid invalid optimizations that throw off accurate measurements. I am experienced with jmh so If I have time I'll try to put together a benchmark. You if course are also welcome to contribute one.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brettwooldridge/NuProcess/issues/73#issuecomment-275836115, or mute the thread https://github.com/notifications/unsubscribe-auth/AT-guYtf9C4e1bspRL0LKjD5cdpuN51Sks5rWwEngaJpZM4LwH9b .

[brettwooldridge]

Fixed in v1.2.0. NuProcess now uses the internal JVM API to spawn processes, so there should be no different in spawn times compared with the Java ProcessBuilder.