Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3E5C2AFE.2070808@ece.gatech.edu>
Date: Tue, 25 Feb 2003 21:48:30 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ralf Habacker <Ralf DOT Habacker AT freenet DOT de>
CC: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] Updated: libtool-devel-20030216, libltdl-20030216
References: <010c01c2dd17$d51d78e0$55a607d5 AT BRAMSCHE>
In-Reply-To: <010c01c2dd17$d51d78e0$55a607d5@BRAMSCHE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ralf Habacker wrote:
>>o speed problem with the internal "win32_libid()" routine is partially
>>fixed -- approx 35% speedup.  Ralf Habacker is working on some
>>modifications to the official fileutils distribution (specifically,
>>file.exe) that should allow an additional 8% speedup without additional
>>changes to libtool.
> 
> 
> Charles, thanks for your efforts with this libtool stuff and I have no problem
> to gone with this already started work, but let me ask one question: Is the
> needed effort hacking the fileutils distro justifiabled for only 8% speedup,
> where you have already got 35% speedup. I'm worry about, that this speedup will
> not be noticeable.

Well, remember that my testing methodology is very rough. I just ran 
win32_libid() on the entire contents of my /lib and /bin dirs.  That 
isn't a normal usage pattern -- I'm *only* checking win32_libid() and 
not any of the other activities that are important in a linkphase.  So 
it is unclear (a) *exactly* how much faster a real link would be given 
this change, and (b) how much faster a super-`file` version would be, in 
a real production environment.

It's possible that *in actual use*, your proposed file changes would 
account for more than 8% -- and my changes would account for less than 35%.

But, those were the numbers I had.

> Should we not instead leave this as it is and concentrate on the way replacing
> import libraries with links as much as can be, which will give much more benefit
> because this case is already as fast as it could be handled by your script (x86
> DLL) ?

It's up to you -- that's why I coded the libtool changes so that your 
improvements could be a "drop in" fix.  I think it'd be "nice" is file 
could tell me that a given file was an import lib or a (regular) lib, 
but it isn't necessary.

There's certainly no rush.

> As I stated before, I have already a libtool hack which covers mostly of the
> needed stuff (a little work is necessary: integrating in recent libtool and fix
> uninstall target)

I look forward to seeing that...

--Chuck




--
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/