This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin build system SOOOO SLOOOWWWW ???


On Thu, Sep 15, 2005 at 04:21:28PM +0200, Jan Schormann wrote:
>c) /bin/sh is now bash, which is now dynamically linked.
>Up until a few months ago, /bin/sh has been "ash", a smaller, but
>less powerfull shell. This has been replaced by bash, to reduce the
>traffic of repeated questions along the lines of "why does my shell
>act different than on linux" (where /bin/sh is bash on most
>distributions).
>
>If I understood the traffic on this list correctly, bash is now
>dynamically linked, which might have an impact on starting it - I can't
>tell.  Hint: Don't start bash so often.  Create fewer processes, but if
>you must, see if you gain by using ash explicitely instead of bash.

I'm not sure what you're getting at here.  bash hasn't changed.  ash
used DLLs, just like bash, but not so many of them.  And, in performance
tests, the difference between bash and ash was not that great.

>To the gurus - is the following correct?
>`echo blub` starts one process, `echo blub | sed -e 's/b/x/g'`
>starts three: "echo", "sed", and "bash" to implement the pipe.

I'm sure I will be one of 47 replies but 'echo blub' does not start any
process since 'echo' is a builtin.  AFAICT, 'echo blub | sed' starts one
process -- the sed process.  If you use a non-builtin on the left side
then two processes would be started.  This is one place where bash is
probably a win over ash.

>d) Beware of lazy evaluation.
>Look at this construct:
>CFLAGS=$(shell find . -type d -name include)

>Read "info make" on setting variables and find out about the difference
>between "=" and ":=".  The above will run the find again for every
>single call to the compiler.  Along with the issues about forking and
>reading directories and small files, this can make a difference of
>*ages*.  Hint: See whether you can use less variables, use ":=" more
>often, etc.  - and don't use "$(shell ...)" anyway, as stated in a).
>Rather, pre-compute makefiles with all the data hardcoded, using ":=".

Good advice.

>e) Reading lots of small files seems more expensive on Windoze.

I don't know if this is true or not.  Windows seems to do a good job
caching files but Cygwin does have a lot of extra overhead for every
file open so it may not matter how well Windows caches.

I've mentioned this many times before (and suspect that someone else is
frantically typing this in right now) but mounting directories which contain
executable files with the -X option makes things a little faster for cygwin:

  mount -f -b -X c:/cygwin/bin /bin
  mount -f -b -X c:/cygwin/bin /usr/bin
  mount -f -b -X c:/cygwin/sbin /sbin
  mount -f -b -X c:/cygwin/usr/sbin /usr/sbin
  mount -f -b -X c:/cygwin/usr/local/bin /usr/local/bin

This should be especially effective if you are accessing files over a remote
share.  OTOH, if you really want speed, you shouldn't be accessing a remote
share at all.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]