Re: Followup on eliminating symlink ReadFile calls -- it's not necessary

[Jonathan Kamens <jik at curl dot com>]

>  Date: Wed, 14 Feb 2001 22:17:09 -0500
>  From: Christopher Faylor <cgf@redhat.com>
>  
>  >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.
>  
>  Thanks for reporting this bug.  Could you provide an example of this
>  behavior, please?

The next time it happens, I will attempt to determine the exact
circumstances and file a bug report.

>  >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.
>  
>  The option is mentioned in the documentation:
>  
>  http://sources.redhat.com/cygwin/cygwin-ug-net/using-utils.html#MOUNT

Yes, and it does indeed mention in a little aside, "This option allows
other files to be marked as executable and avoids the overhead of
opening each file to check for a '#!'."  How silly of us not to
realize from this little snippet of information that our build times
would decrease by 20% if we used this option.

Look.... I can understand why you don't want to make this the default.
Fine.  I can also see that the option we're discussing is documented
in the manuals.  Fine.  All I'm saying is that the documentation isn't
*nearly* explicit enough about the fact that there is a *significant*
performance gain to be had by using "-x", and I think this should be
spelled out more explicitly.

We are not dummies here.  We're developing a product which includes
its own compiler, and we've got some of the best compiler and OS
internals people I've ever worked with.  Several of them have looked
at the "improve Cygwin's performance" problem over and over since we
started using it several years ago, and in all of that time, none of
them ever realized the simple fact that specifying "-x" to mount would
give us a drastic performance improvement.  That's a problem, and
fixing that problem will improve Cygwin.

>  However, we probably could use a tuning cygwin section.

Yes, absolutely.

>  If someone would like to contribute this, I'm sure that it will be
>  included.

If I felt qualified to write it, I would.

  jik

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