www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Any reason why execute() delays?

reply Dukc <ajieskola gmail.com> writes:
I know this is probably abusing D, but I wrote this:

```
enum bridgePath = <path to bridge.exe>;

int main(string[] args)
{  import std.process, std.stdio;
    auto result = execute(["wine", bridgePath] ~ args[1 .. $]);
    result.output.write;
    return result.status;
}
```

However, for some strange reason this one adds up to around 3 
seconds of delay when invoked, compared to invoking `wine 
bridge.exe <args>` directly. If I instead write

```
int main(string[] args)
{  import std.process;
    return spawnProcess(["wine", bridgePath] ~ args[1 .. $]).wait;
}
```

the delay disappears. Does anybody know why?
Jul 27 2020
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Monday, 27 July 2020 at 17:33:23 UTC, Dukc wrote:

 I know this is probably abusing D, but I wrote this:

 ```
 enum bridgePath = <path to bridge.exe>;

 int main(string[] args)
 {  import std.process, std.stdio;
    auto result = execute(["wine", bridgePath] ~ args[1 .. $]);
    result.output.write;
    return result.status;
 }
 ```

 However, for some strange reason this one adds up to around 3 
 seconds of delay when invoked, compared to invoking `wine 
 bridge.exe <args>` directly. If I instead write

 ```
 int main(string[] args)
 {  import std.process;
    return spawnProcess(["wine", bridgePath] ~ args[1 .. 
 $]).wait;
 }
 ```

 the delay disappears. Does anybody know why?


Probably because execute() will also collect output etc. so maybe 
initializing that adds the delay whereas spawnProcess will just 
spawn the process and nothing else.
Jul 27 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/27/20 3:13 PM, bauss wrote:

 On Monday, 27 July 2020 at 17:33:23 UTC, Dukc wrote:

 I know this is probably abusing D, but I wrote this:

 ```
 enum bridgePath = <path to bridge.exe>;

 int main(string[] args)
 {  import std.process, std.stdio;
    auto result = execute(["wine", bridgePath] ~ args[1 .. $]);
    result.output.write;
    return result.status;
 }
 ```

 However, for some strange reason this one adds up to around 3 seconds 
 of delay when invoked, compared to invoking `wine bridge.exe <args>` 
 directly. If I instead write

 ```
 int main(string[] args)
 {  import std.process;
    return spawnProcess(["wine", bridgePath] ~ args[1 .. $]).wait;
 }
 ```

 the delay disappears. Does anybody know why?


 
 Probably because execute() will also collect output etc. so maybe 
 initializing that adds the delay whereas spawnProcess will just spawn 
 the process and nothing else.


3 seconds of delay seems heavy for processing output from the child 
process. Indeed, the difference between execute and spawnProcess is that 
pipes are set up to read the output/error, and those are stored into a 
string before it returns.

But he is also waiting for the process to finish. So I can't see an 
explanation for an *extra* delay.

But what "3 seconds of delay" means could quite depend on what the 
perception is.

spawnProcess is going to inherit the standard handles, and so there is 
no intermediate collecting of output -- you will see output come out 
immediately to the same place as your parent process (probably the 
terminal) as it happens.

I'll give an example, and maybe this is what is happening:

Let's say you have a process that takes 3 seconds to run, and it is 
frequently outputting data to stdout.

If you run it with spawnProcess, you will see these outputs appear as 
they naturally come in.

If you run it with execute, you will see the outputs ONLY after the 
process has ended (3 seconds later).

Is this possibly what is happening?

-Steve
Jul 27 2020
parent Dukc <ajieskola gmail.com> writes:
On Monday, 27 July 2020 at 19:28:40 UTC, Steven Schveighoffer 
wrote:

 If you run it with execute, you will see the outputs ONLY after 
 the process has ended (3 seconds later).

 Is this possibly what is happening?

 -Steve


I don't think so, as the output was given in the very end in both 
cases (I tested with `--help` argument for the invoked 
`bridge.exe`). Also the output wasn't that long, only a few dozen 
lines, so I don't think the overhead of intermediate caching 
could cause it either -unless Wine or Bridge.NET CLI is secretly 
outputting a LOT of backspaces.
Jul 28 2020
prev sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 27 July 2020 at 17:33:23 UTC, Dukc wrote:

 I know this is probably abusing D, but I wrote this:

 ```
 enum bridgePath = <path to bridge.exe>;

 int main(string[] args)
 {  import std.process, std.stdio;
    auto result = execute(["wine", bridgePath] ~ args[1 .. $]);
    result.output.write;
    return result.status;
 }
 ```

 However, for some strange reason this one adds up to around 3 
 seconds of delay when invoked, compared to invoking `wine 
 bridge.exe <args>` directly. If I instead write

 ```
 int main(string[] args)
 {  import std.process;
    return spawnProcess(["wine", bridgePath] ~ args[1 .. 
 $]).wait;
 }
 ```

 the delay disappears. Does anybody know why?


Maybe I remember wrong, but I remember a huge delay specifically 
tied to execute wine, while it performs pretty well in other 
cases.

Not actually tested, but, well ...
Jul 28 2020
parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 28 July 2020 at 07:40:15 UTC, Paolo Invernizzi wrote:

 Maybe I remember wrong, but I remember a huge delay 
 specifically tied to execute wine, while it performs pretty 
 well in other cases.

 Not actually tested, but, well ...


Are you sure it's not the additional delay of creating a new 
wineprefix or starting the wineserver? I ruled off both in my 
case.
Jul 28 2020
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 28 July 2020 at 14:27:43 UTC, Dukc wrote:

 On Tuesday, 28 July 2020 at 07:40:15 UTC, Paolo Invernizzi 
 wrote:

 Maybe I remember wrong, but I remember a huge delay 
 specifically tied to execute wine, while it performs pretty 
 well in other cases.

 Not actually tested, but, well ...


 Are you sure it's not the additional delay of creating a new 
 wineprefix or starting the wineserver? I ruled off both in my 
 case.


No, I remember that the creation of wineprefix was not the 
problem, but well, I'm taking about several years ago ...
Jul 28 2020