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?

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.

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

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 ...

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.

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.

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 ...