Re: [Mingw-users] Really slow executables generated by Msys/Mingw gcc

[Douglas V. <dou...@dy...>]

> 
> > C) Cygwin using -mno-cygwin
> >    1) 66.3
> >    2) 66.0
> >    3) 65.8
> >    4) 25.0
> > D) Msys/MingW
> >    1) 66.4
> >    2) 65.8
> >    3) 65.7
> >    4) 24.9
> > E) .Net
> >     Debug) 20.5
> >     Release) 8.9
> >
> 
> This is simply the cost of using UNIX emulation.  How did you get your 
> timings for .Net?  What happens if you do your timings for C and D in 
> the cmd.exe shell?  What happens if you do your timings for E in the 
> UNIX shell?  There is a lot of code that executes when you spawn a 
> native process from the Cygwin or MSYS runtime to prepare the 
> environment for the native process.
> 
> Earnie Boyd
> 
> http://shop.siebunlimited.com
> 

I've heard this emulation before but what is being emulated here.  Its a
simple executable that doesn't do anything with the OS.  Plus, this
would only be valid for the Cygwin case B.  Cases C and D have nothing
to do with unix emulation. 

I did the timings two ways.  One is, inside the code I call the time()
function at the start and at the end.  While this only provides second
accuracy, its sufficient to demonstrate the problem.  I'm not asking why
one took 20.5 seconds and another took 19.8 seconds.  I'm asking why one
takes 20.5 seconds and another takes 66.0 seconds.  Also, for the times
reported, I actually ran under a cygwin shell using the "time" shell
command.  Now, to make sure that running under the cygwin shell was not
influencing the results, i compared it with the first method just
mentioned above.  If they were within a second, then its a valid
measurement when my primary question is why do cases C and D run three
TIMES as slow.  The times under cygwin shell and cmd.exe shell are
consistant.  The times shown for Case E are under the Unix shell.  The
codes start up right away and immediatly print stuff out to the screen.
If startup was an issue for Cygwin or MSYS I would be waiting 30 secs or
so before I saw output.  Hence these are not the problems.