X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: mwoehlke <mwoehlke AT tibco DOT com>
Subject:  Re: slow share = slow scripts?
Date:  Fri, 26 May 2006 15:18:05 -0500
Lines: 54
Message-ID: <e57npu$6ot$1@sea.gmane.org>
References:  <e577ch$6p3$1 AT sea DOT gmane DOT org> <00b001c680e4$f2d10040$a501a8c0 AT CAM DOT ARTIMI DOT COM>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
In-Reply-To: <00b001c680e4$f2d10040$a501a8c0@CAM.ARTIMI.COM>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

Dave Korn wrote:
> On 26 May 2006 16:38, mwoehlke wrote:
> [snip]
>> Way way back in the OP, I mentioned that Interix doesn't have this
>> problem, which would imply a "design flaw" in Cygwin. Maybe (probably)
>> it is a *necessary* design flaw, BUT...
> 
>   You are now piling pointless and incorrect speculation on your invalid and
> groundless assumptions.  This is a waste of time.

I don't consider reducing the possible cause of the to be a waste of time.

On ONE computer, I am running the same command from the same NFS mount, 
using bash-3.1 in both cases (Interix is 3.1.0, Cygwin is 3.1.17). That 
is a /number/ of controlled variables, with Cygwin/Interix being the 
obviously different one. Under those circumstances, I observe a very 
noticeable difference in execution times.

If that isn't a "bug" - and the (constructive) responses I have gotten 
seem to think it isn't - then it is a problem with the implementation of 
Cygwin on top of the Windows subsystem. I classify that as "a problem 
inherent in the design which is necessitated by the underlying 
architecture". Please try to understand that I am not attempting to 
insult Cygwin. In fact, I am trying to shift blame *away* from Cygwin!

> [snip]
>   See if you can find out where that line of code comes from.  Then read the
> source code to the MSVCRT version of stat, which is shipped with VC, to see
> how it gets the timestamps etc.  Then disassemble FindFirstFileExW in windbg
> and see whether or not it opens the files that it calls.
> 
>   Then post again and explain how you think interix could stat a file without
> having an open handle to it.

Interix is a different /subsystem/, with a totally different means of 
interacting with the underlying file system (particularly NFS) than the 
Windows subsystem. It probably doesn't make anything even resembling the 
same systems calls as Cygwin.

>   Then post again and explain how you managed to tell that cygwin's having to
> open the file is a substantial part of the speed difference between cygwin and
> interix without having once read the source, profiled the code, or timed or
> tested anything.

Sigh. Go back and read my OP. Notice that I attached an strace. Explain 
to me that the detailed profiling/timing information does not qualify as 
"profiling" or "time testing". Please do not make patently false claims 
that I have not attempted to diagnose the problem.

I will of course keep the list up to date of any pertinent findings.

-- 
Matthew
Feed the hippo. Love the hippo. Run from the hippo.


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