Re: fork costs...

[Ralf Wildenhues]

* Eric Blake wrote on Sat, Oct 21, 2006 at 02:37:59PM CEST:
> According to Kyle Sallee on 10/21/2006 1:43 AM:
> > I was looking at
> > /libltdl/config/ltmain.m4sh
> > one of the first uses of tem_deplibs has a nearby call to
> > func_stripname '-R' '' "$libdir"
> > That uses a separate invocation of sed
> > everytime -R is encountered.

Not so if your shell is POSIX compliant enough to understand
  ${foo#bar} and ${foo%bar}

(or maybe our POSIX feature detection in configure is broken?).

> > Even if that seems a bit expensive for
> > calls of libtool not involving a lot of librarie
> > at least the potential invocations of sed
> > to remove the -R could be reduced to only 1.

Again, drop any micro optimizations.  I want to see a relevant test case
for anything that is not obvious.

> > ltmain.m4sh
> > 
> > is rather complex.

Yes.

> > Perhaps more functions would be helpful?

Yes.  But since not even `local' is portable enough, you basically only
have global variables.  It's not trivial to factor this nicely without
getting into all kinds of troubles.

> > What about if the different major tasks of the
> > libtool script were put in separate scripts?

Well.  In fact I have a working patch on my disk to separate link mode
in another scriptlet libtool-link.  It speeds up script execution on my
GNU/Linux by about 20%.  I can post it if people desire, but I'm against
applying it before 2.0, because I don't think the improvement is worth
possible issues now.

> > I understand that you are strongly against using forks
> > where the equivilent can be coded without it.

Not so.  Forking in order to invoke faster tools or to reduce the
complexity order can speed up things significantly, as you also pointed
out.  We are however against any deliberate changes that do not provably
improve things.

> > I would like to know more about how costly forks are
> > on the platforms where it is seriously slow, please.
> > 2432 invocations of /bin/sed during execution of libtool
> > has got to slow it like a sucking chest wound.

GNU/Linux on current hardware can do these in a fraction of a second.

> > Here is my conjecture...

We need code, not conjectures.  Be expected to have it ripped apart or
rejected for portability issues, and to be demanded test cases for any
changes that aren't obviously not changing semantics.  But really it
is not possible to judge optimization issues based on talk.

> > Do you suppose anyone but me would agree that optimizing libtool
> > for best performance on large tasks is better than having libtool
> > optimized for best performance on simple tasks and horrifically
> > slow performance on large tasks?

Definitely, yes.

> > libtool is currently optimized for very small and easy tasks.

Not necessarily.  I'd rather say most parts have never seen much
optimization.

Cheers,
Ralf