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

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

[Jonathan Kamens]

I asserted yesterday that Cygwin Make was being slowed down by the
ReadFile calls necessary to determine if a file should be considered
executable and whether or not it's a symbolic link.  I was only half
right.

DJ Delorie suggested using "mount -x" to eliminate the ReadFile for
determining whether a file is executable, and adding a new mount
option to indicate that there are no symbolic links under a particular
mountpoint, to eliminate the other ReadFile.

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".

This inspired me to do a more careful reading of the code, at which
point I noticed what I should have noticed before -- the ReadFile to
check for a symbolic link doesn't happen unless the system attribute
is set on a file.  In other words, the performance hit we were seeing
in Make was due entirely to the ReadFile checking for executability,
NOT to the ReadFile checking for symbolic links.

Therefore, the current Cygwin already has the ability to eliminate
this performance hit -- you just need to mount filesystems with "-x",
and no additional changes to Cygwin are necessary.

Thanks to everyone who responded to my messages yesterday offering
suggestions that helped me track this down.

Given the magnitude of the performance improvement when "-x" is used,
I wonder if its use should be recommended in the documentation, or
perhaps it should even be the default behavior.

  jik

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

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

[Christopher Faylor]

On Wed, Feb 14, 2001 at 12:46:08PM -0500, Jonathan Kamens wrote:
>DJ Delorie suggested using "mount -x" to eliminate the ReadFile for
>determining whether a file is executable, and adding a new mount
>option to indicate that there are no symbolic links under a particular
>mountpoint, to eliminate the other ReadFile.
>
>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.

>This inspired me to do a more careful reading of the code, at which
>point I noticed what I should have noticed before -- the ReadFile to
>check for a symbolic link doesn't happen unless the system attribute
>is set on a file.  In other words, the performance hit we were seeing
>in Make was due entirely to the ReadFile checking for executability,
>NOT to the ReadFile checking for symbolic links.

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

>Therefore, the current Cygwin already has the ability to eliminate this
>performance hit -- you just need to mount filesystems with "-x", and no
>additional changes to Cygwin are necessary.
>
>Thanks to everyone who responded to my messages yesterday offering
>suggestions that helped me track this down.
>
>Given the magnitude of the performance improvement when "-x" is used, I
>wonder if its use should be recommended in the documentation, or
>perhaps it should even be the default behavior.

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

I've mentioned that -x is a performance win in the mailing list several
times.  The old version of setup.exe used to set this for /bin and
/usr/bin.  I don't know if the current version does or not.

cgf

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

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

[Jonathan Kamens]

>  Date: Wed, 14 Feb 2001 16:13:06 -0500
>  From: Christopher Faylor <cgf@redhat.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

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

[Charles S. Wilson]

Jonathan Kamens wrote:

> The mailing list is not documentation. 

Yes.  It is.  They are called "archives".  They are searchable, so you
can find the information you need.  However, just like "regular"
documentation, not every question has already been asked -- so you might
need to ask a new question once in a while...

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

The net release of cygwin is *NOT* a product.  It is a work in
progress.  It changes daily.  The most effective means of distributing
information about a rapidly changing set of tools is a mailing list or
newsgroup, not a relatively static set of web-based documentation, and
certainly not a printed/bound book.

And yes, you *should* subscribe to the mailing list if you use cygwin. 

However, there should be little need to "pick up tips" to "tweak Cygwin"
if you are doing relatively normal stuff.  It's "effective" in its
default configuration *for most users*.  Not very many people routinely
build applications with, what was it in your case?, "thousands of source
files"?

This is not to say, however, that the documentation couldn't be
improved.  Certainly it could be better.  Many of the questions on this
list, however, ARE answered in the documentation that exists currently. 
The problem is, people don't read it.  So, MORE documentation == more
stuff folks don't read.  That *really* motivates me to add
documentation.  How about you?  (Note: ever look in /usr/doc/Cygwin/*
and /usr/doc/* ?  How many times has Corinna referred people, again and
again, to /usr/doc/Cygwin/inetutils-X.X.X.README or
/usr/doc/Cygwin/openssh-xxxxx.README ?)

And by the way, I personally provide LOTS of documentation with the
packages I've contributed to the cygwin project.  And who can miss my
five-page "Updated: ncurses-5.X-Y" announcement messages?  <Having
established my right to write this rant...>

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

With this, we can all agree.  However, one thing that many folks seem to
miss: not only is the code open source, but also the documentation is,
as well.  PLEASE contribute.  If you're not a programmer, contribute
documentation.  And *hope* people will read it.

--Chuck

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

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

[Christopher Faylor]

On Wed, Feb 14, 2001 at 07:05:56PM -0500, Jonathan Kamens wrote:
>>  Date: Wed, 14 Feb 2001 16:13:06 -0500
>>  From: Christopher Faylor <cgf@redhat.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":

Your original email said this:

On Wed, Feb 14, 2001 at 12:46:08PM -0500, Jonathan Kamens wrote:
>DJ Delorie suggested using "mount -x" to eliminate the ReadFile for
>determining whether a file is executable, and adding a new mount
>option to indicate that there are no symbolic links under a particular
>mountpoint, to eliminate the other ReadFile.

I was referring to the "mount -x" part of what you said, of course.
But it was a petty observation, anyway, and I really should not
have made it.

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

Thanks for reporting this bug.  Could you provide an example of this
behavior, please?

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

There is a possibility that some harm, or at least some confusion, could
come from it.  Windows could interpret the file as a .com file and try
to execute it as arbitrary code.

You actually see this occasionally when Windows tries to execute a
Cygwin symlink when the system attribute has been removed.

>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 am interested in correctness, not speed.  I am not going to turn on
the 'x' bit for every file just so that all 'configure; make's will be
faster.  You're welcome to make this decision for yourself, however,
and you've obviously done so.

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

The option is mentioned in the documentation:

http://sources.redhat.com/cygwin/cygwin-ug-net/using-utils.html#MOUNT

However, we probably could use a tuning cygwin section.  If someone
would like to contribute this, I'm sure that it will be included.

Btw, you can also use this option (and any mount option, actually) on
individual files if you want to get pinpoint control.

I should also point out that the currently undocumented "-X" (uppercase)
flag may be useful for directories which are populated only by cygwin
executables.  This should decrease the overhead in spawn and fork
slightly.

cgf

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

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

[Jonathan Kamens]

>  Date: Wed, 14 Feb 2001 20:49:28 -0500
>  From: "Charles S. Wilson" <cwilson@ece.gatech.edu>
>  
>  > The mailing list is not documentation. 
>  
>  Yes.  It is.  They are called "archives".

Random users have no idea what to search for in the mailing list
archives to find out that specifying "-x" to mount will cause a
performance improvement.  In fact, it won't occur to most random users
that there are *any* ways to tweak Cygwin to improve its performance.
They will assume, reasonably so, that Cygwin's performance has been
tweaked by its developers, and they just have to live with it.

I repeat my assertion that random end users should not have to consult
the mailing list to find out non-esoteric information which is
relevant to their usage of the product.  The fact that there is a
simple configuration change which can give them a double-digit
improvement in performance is certainly relevant and certainly should
NOT be esoteric.

>  The net release of cygwin is *NOT* a product.  It is a work in
>  progress.  It changes daily.  The most effective means of
>  distributing information about a rapidly changing set of tools is a
>  mailing list or newsgroup, not a relatively static set of web-based
>  documentation, and certainly not a printed/bound book.

First of all, the fact that "mount -x" will improve performance is
certainly not something that is "rapidly changing."  It has apparently
been true for a long time.

Second, Cygwin may not be a "product" right now, but it certainly
*wants* to be one, doesn't it?  Isn't there a goal here that Cygwin
will be a stable, widely used, and "commodity" software package?  Or
it going to be a cute little thing used by a smale cadre of hackers
forever?

If you are saying that you don't think Cygwin ever, at any point in
the future, needs comprehensive documentation, then I suppose there
isn't much for us to talk about, because I completely disagree.  If
you agree that Cygwin *does* eventually need such documentation, then
we should be improving the documentation along with the software, not
repeatedly saying, "Well, we don't need documentation now because the
software is unstable," over and over again, until we suddenly find
ourselves at the point where the software is stable but we still don't
have the documentation.

The fact that there is so much documentation would seem to indicate
that there are people who believe that we should have such
documentation.

>  And yes, you *should* subscribe to the mailing list if you use cygwin. 

I hope that the maintainers of Cygwin do not believe that should be
true forever.

>  This is not to say, however, that the documentation couldn't be
>  improved.  Certainly it could be better.  Many of the questions on this
>  list, however, ARE answered in the documentation that exists currently. 
>  The problem is, people don't read it.

I and my coworkers do.  If the fact that we could improve our
performance by 20% merely by using "mount -x" had been documented, we
would have learned about it long ago.

  jik

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

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

[Jonathan Kamens]

>  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

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

[Christopher Faylor]

On Thu, Feb 15, 2001 at 08:57:36AM -0500, Jonathan Kamens wrote:
>Second, Cygwin may not be a "product" right now, but it certainly
>*wants* to be one, doesn't it?  Isn't there a goal here that Cygwin
>will be a stable, widely used, and "commodity" software package?  Or
>it going to be a cute little thing used by a smale cadre of hackers
>forever?

Cygwin "wants" to be a typical free software project.  That's it.  That
means that it will be subject to the usual number of indignant
complaints because things aren't perfect.

>If you are saying that you don't think Cygwin ever, at any point in
>the future, needs comprehensive documentation, then I suppose there
>isn't much for us to talk about, because I completely disagree.  If
>you agree that Cygwin *does* eventually need such documentation, then
>we should be improving the documentation along with the software, not
>repeatedly saying, "Well, we don't need documentation now because the
>software is unstable," over and over again, until we suddenly find
>ourselves at the point where the software is stable but we still don't
>have the documentation.
>
>The fact that there is so much documentation would seem to indicate
>that there are people who believe that we should have such
>documentation.

Who is this "we" you are talking about?  No one has said or implied that
improvements to the documentation are not desirable.  Are you thinking
about contributing documentation?

If not, then let's stop this thread now.  It's not going anywhere.

cgf

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

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

[Warren Young]

Jonathan Kamens wrote:
> 
> >  > The mailing list is not documentation.
> >
> >  Yes.  It is.  They are called "archives".
> 
> Random users have no idea what to search for in the mailing list
> archives to find out that specifying "-x" to mount will cause a
> performance improvement.  

As maintainer of two FAQs, may I humbly point out that this is grist for
a FAQ mill.  Someone needs to be monitoring the mailing list, looking
for questions that come up a lot and add them to the FAQ, even if only
as a link into the mailing list archives.  This solves the "mailing list
is not documentation" problem: the FAQ item puts a useful title on the
solution, like "How do I increase Cygwin performance?"

No, sorry, I am not volunteering.  :)  I don't want to maintain 3 FAQs.  
--                                                   _
= 'Net Address: http://www.cyberport.com/~tangent | / \  ASCII Ribbon
= ICBM Address: 36.82740N, 108.02040W, alt. 1714m | \ /  Campaign
=                                                 |  X   Against
= Chance favors the prepared mind.                | / \  HTML Mail

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

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

[Warren Young]

Jonathan Kamens wrote:
> 
> If I felt qualified to write it, I would.

Not to harp on my creds, but as maintainer of two FAQs, I find that one
of the fastest ways to get the right answer is to put the wrong answer
in the FAQ.  ;)  Your qualifications are unimportant, only your interest
and time matter.  You only risk temporarily embarrassing yourself, but
that only encourages you to research your answers better before posting
them.

I think you might be an ideal FAQ maintainer.  As Cygwin is so important
to your company, they should even be willing to donate some of your time
to the effort.  You just need to explain to them that maintaining a FAQ
is a great learning experience.  I know I've learned a hell of a lot
more about Winsock and Palm programming over the time I've maintained my
two FAQs than if I'd been left to learning only what I _wanted_ to know.
--                                                   _
= 'Net Address: http://www.cyberport.com/~tangent | / \  ASCII Ribbon
= ICBM Address: 36.82740N, 108.02040W, alt. 1714m | \ /  Campaign
=                                                 |  X   Against
= Chance favors the prepared mind.                | / \  HTML Mail

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

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

[Christopher Faylor]

On Thu, Feb 15, 2001 at 12:49:16PM -0700, Warren Young wrote:
>Jonathan Kamens wrote:
>> 
>> >  > The mailing list is not documentation.
>> >
>> >  Yes.  It is.  They are called "archives".
>> 
>> Random users have no idea what to search for in the mailing list
>> archives to find out that specifying "-x" to mount will cause a
>> performance improvement.  
>
>As maintainer of two FAQs, may I humbly point out that this is grist for
>a FAQ mill.  Someone needs to be monitoring the mailing list, looking
>for questions that come up a lot and add them to the FAQ, even if only
>as a link into the mailing list archives.  This solves the "mailing list
>is not documentation" problem: the FAQ item puts a useful title on the
>solution, like "How do I increase Cygwin performance?"
>
>No, sorry, I am not volunteering.  :)  I don't want to maintain 3 FAQs.  

Been here long?  We have a FAQ maintainer.  (David, you are still there,
right?)

I don't agree that this is FAQ material.  What is the FAQ?

  "How do I make my file lookups faster?"

  Use "mount -x"

I don't think so.  There are too many gotchas with doing this and I think
that they fall outside of the role of a FAQ, if for no other reason
than this *isn't* a frequently asked question.

Updating the documentation, however, is the right way to go.

cgf

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

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

[David Starks-Browning]

On Thursday 15 Feb 01, Christopher Faylor writes:
> >....  Someone needs to be monitoring the mailing list, looking
> >for questions that come up a lot and add them to the FAQ, even if only
> >as a link into the mailing list archives.  This solves the "mailing list
> >is not documentation" problem: the FAQ item puts a useful title on the
> >solution, like "How do I increase Cygwin performance?"
> >
> >No, sorry, I am not volunteering.  :)  I don't want to maintain 3 FAQs.  
> 
> Been here long?  We have a FAQ maintainer.  (David, you are still there,
> right?)

I'm still alive, however, I have not been monitoring the main cygwin
list since about mid-December.  I was away from mail for a month, and
haven't since mustered the courage to tackle the backlog of about 10^6
messages that must sit there by now.  That, and I thought I could get
some other things under control first.  Those things have taken longer
than I thought they would.

I fully plan to get back on track, but it may take another week or so
to catch up completely.  Of course, if someone else can do a better
job, we can talk about that too.

Cheers,
David


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

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

[Christopher Faylor]

On Thu, Feb 15, 2001 at 11:17:14PM +0000, David Starks-Browning wrote:
>On Thursday 15 Feb 01, Christopher Faylor writes:
>> >....  Someone needs to be monitoring the mailing list, looking
>> >for questions that come up a lot and add them to the FAQ, even if only
>> >as a link into the mailing list archives.  This solves the "mailing list
>> >is not documentation" problem: the FAQ item puts a useful title on the
>> >solution, like "How do I increase Cygwin performance?"
>> >
>> >No, sorry, I am not volunteering.  :)  I don't want to maintain 3 FAQs.  
>> 
>> Been here long?  We have a FAQ maintainer.  (David, you are still there,
>> right?)
>
>I'm still alive, however, I have not been monitoring the main cygwin
>list since about mid-December.  I was away from mail for a month, and
>haven't since mustered the courage to tackle the backlog of about 10^6
>messages that must sit there by now.  That, and I thought I could get
>some other things under control first.  Those things have taken longer
>than I thought they would.
>
>I fully plan to get back on track, but it may take another week or so
>to catch up completely.  Of course, if someone else can do a better
>job, we can talk about that too.

I haven't seen any real FAQ emergencies for a while, so there is no
need to panic.  :-)

cgf

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

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

[Corinna Vinschen]

On Thu, Feb 15, 2001 at 07:37:35PM -0500, Christopher Faylor wrote:
> On Thu, Feb 15, 2001 at 11:17:14PM +0000, David Starks-Browning wrote:
> >I fully plan to get back on track, but it may take another week or so
> >to catch up completely.  Of course, if someone else can do a better
> >job, we can talk about that too.
> 
> I haven't seen any real FAQ emergencies for a while, so there is no
> need to panic.  :-)

Yeah, probably because you're doing a real great job maintaining the FAQs!

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

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

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

[Warren Young]

Christopher Faylor wrote:
> 
> I don't agree that this is FAQ material.  What is the FAQ?
> 
>   "How do I make my file lookups faster?"

No, the FAQ is, "how can I increase performance".  This would require an
article-length answer, with all the possible tweaks and their
disadvantages.  "mount -x" is just one of the tweaks, and of course the
answer would have to detail what you gain and what you give up by using
it.

> if for no other reason
> than this *isn't* a frequently asked question.

It's infrequent because most people just quietly tolerate Cygwin's
performance hit.  If they knew it was possible to increase its
performance in certain circumstances, I think those same people would
then quietly begin tuning their systems.

> Updating the documentation, however, is the right way to go.

Maybe we're disagreeing on location and form rather than content.
--                                                   _
= 'Net Address: http://www.cyberport.com/~tangent | / \  ASCII Ribbon
= ICBM Address: 36.82740N, 108.02040W, alt. 1714m | \ /  Campaign
=                                                 |  X   Against
= Chance favors the prepared mind.                | / \  HTML Mail

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

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

[Christopher Faylor]

On Fri, Feb 16, 2001 at 02:39:35AM -0700, Warren Young wrote:
>Christopher Faylor wrote:
>> 
>> I don't agree that this is FAQ material.  What is the FAQ?
>> 
>>   "How do I make my file lookups faster?"
>
>No, the FAQ is, "how can I increase performance".  This would require an
>article-length answer,

I.e., something which is inappropriate for the FAQ.

>> if for no other reason
>> than this *isn't* a frequently asked question.
>
>It's infrequent because most people just quietly tolerate Cygwin's
>performance hit.  If they knew it was possible to increase its
>performance in certain circumstances, I think those same people would
>then quietly begin tuning their systems.

Yeah, lucky break for us that it isn't asked frequently.  I can imagine
that there are a lot of things that people quietly accept that they
could ask about.  However since they aren't "Frequently Asked" they
don't go into the FAQ.

>> Updating the documentation, however, is the right way to go.
>
>Maybe we're disagreeing on location and form rather than content.

I'm still waiting for someone to write this, however.

As always, people write volumes about their ideas on how things should
be but "aren't qualified" to write the actual thing themselves.

cgf

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

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

[Robert Melchers]

Robert Melchers wrote:
>
> This may or may not be relevant, We have recently upgraded our Virus
scanner to McAfee Virus Scan 4.5 from 4.x. our build of > 200 files has now
slowed by
> a factor of 5-10x. The only answer is to exit the scanner, The effect can
be seen using Task Manager, with the scanner active Make (and its sub
processes)
> get about 40% of the processor, and the Idle process the rest, exit this
scanner and Make get 100%. The source directory and Tools directories are
both
> excluded from the scanner.
> This is a known FAQed issue. Earnie.

I knew about the FAQ but I never noticed the slow down until the latest
scanner was installed. My guess is that their old problem is back again.

Robert.


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

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

[Earnie Boyd]

Robert Melchers wrote:
> 
> This may or may not be relevant, We have recently upgraded our Virus scanner to McAfee Virus Scan 4.5 from 4.x. our build of > 200 files has now slowed by
> a factor of 5-10x. The only answer is to exit the scanner, The effect can be seen using Task Manager, with the scanner active Make (and its sub processes)
> get about 40% of the processor, and the Idle process the rest, exit this scanner and Make get 100%. The source directory and Tools directories are both
> excluded from the scanner.
> 

This is a known FAQed issue.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

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

[Robert Melchers]

This may or may not be relevant, We have recently upgraded our Virus scanner to McAfee Virus Scan 4.5 from 4.x. our build of > 200 files has now slowed by 
a factor of 5-10x. The only answer is to exit the scanner, The effect can be seen using Task Manager, with the scanner active Make (and its sub processes) 
get about 40% of the processor, and the Idle process the rest, exit this scanner and Make get 100%. The source directory and Tools directories are both 
excluded from the scanner.

Robert.



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