[M3devel] possible cygwin createprocess/fork cost measurements..

[Jay]

 I ran some mostly scientific measures of Cygwin.  On one machine, no reboots, one OS, one set of files. x86, single proc, Windows 2000 (I'll go back to XP soon).  It shows that..well, at least that wrapping Cygwin processes with sh is VERY expensive.  Like, the data isn't yet complete, but this could cut building Cygwin libm3  from around 100 seconds to around 20 seconds. Not counting the Modula-3 front end time.  Just cm3cg+as.
 cd libm3\NT386GNU  having already built successfully, all the *.ic *.mc files are present 
 
 cm3cg not wrapped with sh (F1)  Repeated runs.   28 seconds (other stuff running on machine)    16 seconds   13 seconds (13.?)   13.8 seconds   14.01 seconds   13.3 seconds    now add the -o flag   13.64 seconds   14.07 seconds    now without echoing   13.22 seconds   13.18 seconds  
 
 cm3cg wrapped with sh (F2)  51 seconds  51.35 seconds  51.19 seconds  50.88 seconds   now add the -o flag  51.76 seconds    now without echoing  51.05 seconds 
 These runs did NOT have -o flags, but subsequent runs with -o were about the same.  I added -o so I could run the as variations. 
 now the same with .s  note that due to the way the above worked, I just have *.s files, and  not the usual *.is and *.ms  
 
 as not wrapped with sh (F3)   5.6 seconds   5.28 seconds     now remove echo   5.08 seconds   5.08 seconds   5.04 seconds    forgot -o flag, oh well, enough data 
 as wrapped with sh (F4)   43 seconds   43.56 seconds    forgot -o flag, oh well, enough data  
 What is not yet confirmed is:   1) Does cm3 wrap everything with sh?   2) Does calling m3cg/as from cm3 have these costs? 
 Very clear:    Wrapping stuff with sh on Cygwin is expensive! 
 
  Actions:    Confirm this cost is being paid by cm3.     Either:      1) implement some "batch modes" in cm3 and/or cm3cg      2) or maybe, um, just make sure that cm3 does not wrap with sh, and        if cm3 itself causes this slowdown, because of how Cygwin works, try        interposing a small Win32 helper app. I think Cygwin handles runnig        Win32 apps and being run from Win32 apps differently than Cygwin running        Cygwin -- i.e. not slowly. I'll see. Could be that creating twice the number       of processes, in order to avoid Cygwin running Cygwin, could be faster. Not yet known. 
 
 Maybe use system() instead vfork() + exec()? Odd, though, vfork instead of fork is supposed to help.
  Here is the test code, you edit it to run one case or another: 
 
 
@if not "%1" == "" goto :%1 at rem \cygwin\bin\time cmd /c %~f0 F1 at rem \cygwin\bin\time cmd /c %~f0 F2 at rem \cygwin\bin\time cmd /c %~f0 F3@\cygwin\bin\time cmd /c %~f0 F4 at goto :eof
 
 
:F1 at echo off at del *s *ofor %%a in (*.ic *.mc) do cm3cg -quiet %%a -o %%a.s"goto :eof
 
 
:F2 at echo off at del *s *ofor %%a in (*.ic *.mc) do sh -c "cm3cg -quiet %%a -o %%a.s"goto :eof
 
 
:F3 at del *o at echo offfor %%a in (*.s) do as %%agoto :eof
 
 
:F4 at del *ofor %%a in (*.s) do sh -c "as %%a"goto :eof
 
 - Jay
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080317/e33b8768/attachment-0001.html>