Re: Severe performance problem and proposed solution

[Paul Eggert]

> From: Zack Weinberg <address@hidden>
> Date: Tue, 26 Feb 2002 17:21:14 -0800
> 
> In this case, we know that the problem is due to the creation of
> thousands of temporary files which each subshell invocation creates
> hard links to.  If, I say if, someone can generate a small script
> that causes the shell to do this, then it could look into /tmp for the
> scratch files.

But such a method cannot be reliable in general, since you don't know
what other processes are doing.  Some other process may be running
'configure' with a buggy shell at the same time that you're running
'configure' with a working shell (not entirely implausible, if you're
using a parallelized 'make').

> > Can you assume that the people with the performance problems have
> > access to a better shell like Bash?  If so, you can ask them to put
> > CONFIG_SHELL=/path/to/bash before running configure.  That should
> > solve the problem.
> 
> That is the currently recommended workaround; however, we would prefer
> an automatic solution.

Currently 'configure' switches to Bash if the current shell mishandles
LINENO and if Bash exists and handles LINENO correctly.  We could
modify things so that instead it switches to Bash if the current shell
is not Bash and if Bash exists and handles LINENO correctly.  That
would be a bit of a hack, but it would do the trick, no?

> > For example, you might try using 'case' rather than 'if'.  Sometimes
> > that avoids weird performance bugs in /bin/sh.

> Oh really?  That might indeed be worth trying, thanks.

I know that, in old shells, 'case ...' is much faster than 'if test
...' because the latter forks subprocesses whereas the former does
not.  This problem occurs in the Unix Version 7 Bourne shell, for
example.  It's conceivable that this is related to the problem.  (A
slender reed, I admit.)