Mail Archives: cygwin/2005/09/15/10:56:00
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/
- Raw text -