This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030121-1
Okay, using a more 'fair' metric on speed (don't throw a lot of
'unknowns' at the libid() function; libtool presumably will only present
things that IT believes are libraries or DLLs for identification.
Unless the user mis-specifies something. So, using THIS test routine,
which only grabs .dll.a, .a, .dll, and .exe files:
time for fn in /usr/bin/*.exe /usr/bin/*.dll /usr/lib/*.a ; do
echo $fn : `./cygwin_libid $fn`
I get the following results:
best case, tweaked Ralf script:
best case, paranoid Chuck script:
That is, if current is a "100%", then Ralf's is a "58%" and my version
is a "65%".
Here's what the extra 7% execution speed buys you: my version is never
fooled by merely renaming the file. It ALWAYS looks at the actual
content and format of the file itself (or it will follow a symlink and
look at the contents of the target).
How'd I speed it up, while still being paranoid like the original? Try
to spawn as few subsidiary processes as possible. When possible, use
sh's case command for simple regex matching, not grep -E. Reduce one
long chain of pipes and spawned programs to a single (complicated) sed
command. Use 'head' to discard (and not wait for) long extraneous outputs.
Some of these ideas were originally proposed by Ralf, but this version
is sufficiently "mine" that I have no problem sumitting to the libtool
Ralf -- please drop my 'final' script into one of your generated
libtools and run your tests (what? rebuilding KDE?) on it, and let me
know what you think. (Oh, and since (a) 'file' execution speed is
invariant with target size, and (b) we match *DLL* and *executable*
separately, if you are linking directly to DLLs -- as I believe Ralf's
KDE build does -- then my version is almost as fast (<1% difference) as
Ralf's "check the name of the file only" version)
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html