Very slow "Launch External Process" execution


I discovered that LEP takes a minimum of over 200ms to execute the simplest command (both in interpreted and compiled mode) in v18 thru v18R2 on the Mac.

I was trying to replace the use of a plugin (the excellent Scripting Tools by Pluggers) to allow for preemptive web processes and discovered that LEP takes 60x longer than calling SCT Do Shellscript for any command, even the simple /bin/ls command. I was quite surprised as LEP is less functional than the plugin command which even supports shell execution.

Am I doing something wrong?

Unfortunately, LEP has always been very slow on on MacOS if you need to get the command output. Only solution would be a preemptive plugin or maybe start a service and access via HTTP Client or some other method. Perhaps PHP Execute.

Thanks for your suggestions, it made me think of New Signal used with call worker. I simply call a cooperative worker with a signal from the preemptive thread which then waits for the trigger and gets the result back. This allows the use of non-preemptive plugins (aren’t they all non-preemptive?) from a preemptive thread with almost no delay. Calling a worker with signal and executing the plugin call inside the worker was 60x faster than using LEP. It works great, but this makes LEP look even worse :slight_smile:

That is a good solution for using a non-preemptive plugin. Signal works well for returning values from execution in other processes.

No, plugins can be preemptive. I wrote a networking plugin for Postgres. I know Rob was waiting for more of the plugin entry points to be preemptive before trying to convert his existing plugins. You might check with him on the possibility of upgrading the plugin. See

No, unfortunately you are not doing anything wrong.

This has been the case for many years. This is what I call the “LEP tax”. I used to evaluate around 300 ms. Don’t know why this is.

You are right about the LEP tax, I can only speculate that the public services you get in return are the stdOut and stdErr. In other words, maybe the polling is a bit too aggressive. I don’t know if it makes any difference if the receiver variables were typed as BLOB instead of text. Maybe it is negligible, I don’t know.

Many of the Pluggers plugins are at least partially pre-emptive. If you look at the manifest.json file within the plugin, the pre-emptive state of each plugin command is documented.