time for fn in /usr/bin/*.exe /usr/bin/*.dll /usr/lib/*.a ; do
echo $fn : `./cygwin_libid $fn`
done
I get the following results:
Current win32_libid():
real 3m25.480s
user 2m0.436s
sys 1m24.073s
best case, tweaked Ralf script:
real 1m59.535s
user 1m11.151s
sys 0m56.012s
best case, paranoid Chuck script:
real 2m13.261s
user 1m12.385s
sys 0m54.422s
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 folks.
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)
--Chuck
cygwin_libid_orig
Description: application/java-applet
cygwin_libid_ralf_tweaked
Description: application/java-applet
cygwin_libid_chuck_final
Description: application/java-applet
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
