X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.0 required=5.0	tests=AWL,BAYES_40,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Message-ID: <4C059C9E.4030206@cs.umass.edu>
Date: Tue, 01 Jun 2010 19:49:50 -0400
From: Eliot Moss <moss AT cs DOT umass DOT edu>
Reply-To: moss AT cs DOT umass DOT edu
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin Performance and stat()
References: <efe8a37b2e4466daa7b6eb1aa610c3d7 DOT squirrel AT www DOT webmail DOT wingert DOT org> <20100530170747 DOT GA8605 AT ednor DOT casa DOT cgf DOT cx> <f460895a8fc53da26cb91259a4005da2 DOT squirrel AT www DOT webmail DOT wingert DOT org> <4C03D6C5 DOT 4050004 AT x-ray DOT at> <80373222dd5d43b134a5ede7036e7674 DOT squirrel AT www DOT webmail DOT wingert DOT org> <4C058753 DOT 1030400 AT cygwin DOT com>
In-Reply-To: <4C058753.1030400@cygwin.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On 6/1/2010 6:18 PM, Larry Hall (Cygwin) wrote:

> Thanks for this information and perhaps I'm wrong but I don't believe
> anyone in this thread thought that you were lying when you noted issues
> with the performance of stat(). ;-) But providing a variant of stat()
> along the lines of what you propose above is not practical for all the
> reasons already stated. I believe we would all like stat() to be
> quicker but we need something that solves the root of the problem and
> not partial, hidden solutions that are problematic to use.

Agreed. But here's a wondering. What if, perhaps via autoconf flags
or something (I know next to nothing about autoconf, so please ignore
that part of it if it is completely off base), we could make it
possible for someone who is porting a package to cygwin to indicate
what features of stat that program needs.  This would be optional
to do, and could be applied as porters have time, etc.  Now ideally
such an approach could be applied differentially to different calls
of stat, but even if it is global, maybe it would help speed up
some programs a lot ...

Again, just wondering about whether something like this might
get the community somewhere better in performance ...

Regards -- Eliot Moss

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple