delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2001/02/14/19:15:51

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: 14 Feb 2001 19:05:56 -0500
Message-ID: <20010215000556.23697.qmail@lizard.curl.com>
From: Jonathan Kamens <jik AT curl DOT com>
To: cygwin AT cygwin DOT com
CC: cygwin AT cygwin DOT com
In-reply-to: <20010214161306.D18567@redhat.com> (message from Christopher
Faylor on Wed, 14 Feb 2001 16:13:06 -0500)
Subject: Re: Followup on eliminating symlink ReadFile calls -- it's not necessary
References: <20010214174608 DOT 17253 DOT qmail AT lizard DOT curl DOT com> <20010214161306 DOT D18567 AT redhat DOT com>

>  Date: Wed, 14 Feb 2001 16:13:06 -0500
>  From: Christopher Faylor <cgf AT redhat DOT com>
>  
>  >I implemented his suggestion, adding a "-l" flag and a corresponding
>  >MOUNT_NO_SYMLINKS flag, and did some performance testing on the
>  >result.  I was surprise to discover that mounting with this option
>  >didn't provide any additional performance improvement over "-x".
>  
>  Actually, I suggested this.

No, I'm afraid not.

You suggested using "mount -x":

=Actually, I wonder if just mounting the directory with the execute
=bit set ("mount -x c:\bin /bin") would solve this.

DJ Delorie suggested adding a new option to suppress the ReadFile for
symbolic links too:

=Perhaps you could propose a set of mount flags to optimize common
=situations?  We already have one to avoid the read-for-execute test,
=perhaps you could work on an assume-no-symlinks flag?  Then we
=wouldn't need a custom make.exe (or any other program).

>  I also mentioned that two ReadFiles were not happening for stat()
>  so this should not be a surprise.

Yes, you did, but you did not give any details of what mechanism you
used to accomplish this, and when I sent you private E-mail saying
that I couldn't figure out how the code was doing what you said it was
doing, you did not respond.

What "surprised" me was not that you were right, but rather the clever
use of the system attribute to mark which files might be symlinks,
something which I didn't notice initially and which you didn't mention
at all in your messages.

>  Setting execute permissions on everything is not a generically good
>  solution.  It means that cygwin will try to execute things like "foo.c".

1) This happens to me already in Cygwin, even when I don't use "mount
-x".  Cygwin's and bash's mechanisms for figuring out whether a file
can be executed are hardly foolproof.

2) I do not think that the fact that Cygwin will try to run a
non-program file if someone makes the mistake of typing its name as a
command is a particularly big deal.  It's highly unlikely that any
harm would come of it.  And the performance improvement from "mount
-x" is really phenomenal; I think it clearly outweighs the risk.

To see what I mean, try doing "configure; make" on Cygwin with and
without "mount -x".  On my machine, it takes 16:54 without "-x" and
13:31 with it, an improvement of 20%!

>  I've mentioned that -x is a performance win in the mailing list several
>  times.

The mailing list is not documentation.  People should be able to
download and use Cygwin in an effective manner by consulting its
documentation.  They should not need to subscribe to the mailing list
and pick up tips over time just to learn how to tweak Cygwin into an
effective configuration.

If you've had to mention it on the mailing list several times, that's
all the more indication that it should be documented in the persistent
documentation.

  jik

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019