Fwd: curious...

[Kyle Sallee]

There was a signifigant delay between when
I sent a request to join the list and the confirmation email.
Consequently, I conjectured that there would be no confirmation email.
Therefore, I sent an email to the list before confirming joining.
Consequently, I received a bounce awaiting moderator approval.
Therefore, I am resending the email now that I have confirmed joining.


---------- Forwarded message ----------
From: Kyle Sallee <address@hidden>
Date: Oct 20, 2006 2:21 PM
Subject: curious...
To: address@hidden


I was looking at a 26M sh -x trace of an invocation of libtool
while compiling koffice to see why so many CPU cycles were
being spent on running the libtool shell script.
What I saw reminds me of rolling snowballs.
I see these case statements that build up variables such as
deplibs=
and it rolls larger, larger, larger, etc...

If I grep out lines containing

newdependency_libs=

The file shrinks from 26M to just 3.9M

I am guessing if the snowballing effect can be eliminated
that the execution of libtool on should become much faster.

Is it out of the question to keep lists separated by line feeds
instead of spaces and then use the sort and uniq instead
of case statements?

There are also some parts that look obviously slow...


   # Find all interdependent deplibs by searching for libraries
   # that are linked more than once (e.g. -la -lb -la)
   for deplib in $deplibs; do
     if test "X$duplicate_deps" = "Xyes" ; then
       case "$libs " in
       *" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;;
       esac
     fi
     libs="$libs $deplib"
   done


Take the above for example...

That test is done for each deplib in $deplibs
But if duplicate_deps is yes for one it is yes for all.
So why not do that check just once?

if test "X$duplicate_deps" = "Xyes" ; then
 for deplib in $deplibs; do
   case "$libs " in
     *" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;;
   esac
 done
else
 libs="$deplibs"
fi

Why roll a snowball if duplicate_deps is not yes?

And for the for loop inside, perhaps that could be done
with utilities?

specialdeplibs="$( echo "$deplibs" | tr ' ' '\n' | sort | uniq -d )"
libs="$( echo "$deplibs" | tr ' ' '\n' | sort -u )"


The above example was not from a part of libtool that
was necessarily snowballing signifigantly on that invocation.
But there is probably some slowing down involving loops
that assign newdependency_libs=

Does the use of backticks or $( subshells break portability of libtool?
What about the use of sort and uniq?
I am guessing it should be permitted becuase
I can grep some places in libtool where | sort | uniq are used.

I appreciate what libtool does and libtool's portability.
However, some modification could probably yield
several magnitudes of execution speed increase.

Would you like me to hack a little on libtool just to
increase it's execution speed or are such changes
trivial to accomplish now that I mentioned it?