Are System Calls on Windows Inherently Slower Than Linux

Why should I Minimize the use of system call in my code?

Because most system calls have an inherent overhead. A system call is a means of tapping into the kernel, a controlled gateway towards obtaining some service.

When performing a system call, some actions are taken (warning, it's a simplification):

• You invoke a library (wrapper) function
• The function puts the arguments where they are expected. Also the function puts the number of the system call in eax
• The function calls a trap (int 0x80 or whatever)
• The processor is switched to kernel mode
• The kernel invokes some system_call routine
• The registers are saved onto the kernel stack
• The arguments are checked to be valid
• The action is performed
• The registers are restored from the kernel stack
• The processor is returned to user mode
• The function (finally...) returns

And I probably forgot some of the steps. Doesn't this sound like a lot of work ? All you wanted is the bold part. The rest is overhead.

How to speed up Cygwin?

The problem you're running into is not some arbitrary limit in Cygwin that you can make go away with a settings change. It's an inherent aspect of the way Cygwin has to work to get the POSIX semantics programs built under it expect.

The POSIX fork() system call has no native equivalent on Windows, so Cygwin is forced to emulate it in a very inefficient way. Shell scripts cause a call to fork() every time they execute an external process, which happens quite a lot since the shell script languages are so impoverished relative to what we'd normally call a programming language. External programs are how shell scripts get anything of consequence done.

There are other inefficiencies in Cygwin, though if you profiled it, you'd probably find that that's the number one speed hit. In most places, the Cygwin layer between a program built using it and the underlying OS is pretty thin. The developers of Cygwin take a lot of pains to keep the layer as thin as possible while still providing correct POSIX semantics. The current uncommon thickness in the fork() call emulation is unavoidable short of Microsoft adding a native fork() type facility to their OS. Their incentives to do that aren't very good.

The solutions posted above as comments aren't bad.

Another possibility is to go through the drush script and see if there are calls to external programs you can replace with shell intrinsics or more efficient constructs. I wouldn't expect a huge speed improvement by doing that, but it has the nice property that you'll speed things up on the Linux side as well. (fork() is efficient on Linux, but starting external programs is still a big speed hit that you may not have to pay as often as you currently do.) For instance:

numlines=`grep somepattern $somefile | wc -l`
if [ $numlines -gt 0 ] ; then ...

would run faster as:

if grep -q somepattern $somefile ; then ...

The first version is arguably clearer, but it requires at least three external program invocations, and with primitive shells, four. (Do you see all of them?) The replacement requires only one external program invocation.

What does 128-bit OS mean to a software developer?

It means that the Windows\System32 directory contains 128bit DLLs, 64bit DLLs in WINDOWS\SysWOW128, and 32bit DLLs are in WINDOWS\SysWOW64WOW128.

In the registry, 128bit applications store data under HKEY_LOCAL_MACHINE/SOFTWARE, 64bit applications under HKEY_LOCAL_MACHINE/SOFTWARE/Wow12864Node, and 32bit applications under HKEY_LOCAL_MACHINE/SOFTWARE/Wow1286432Node.

This strategy will confuse virus and malware developers so much that they give up. Registered developers will receive a large poster to illustrate the redirects and mappings.

---

Related Topics