Re: Time taken for ls -la --color=yes

Re: Time taken for ls -la --color=yes

[N8TM]

In a message dated 3/7/99 5:41:23 PM Pacific Standard Time,
treaves@y11a165.neo.rr.com writes:

<< 	When I execute this on my machine, a dual PII 266 with 192 meg memory & a
Seagate Cheeta 10,000rpm hard drive, with three other applications running
(Netscape, mail, a data conversion app), it takes a good 1.5 to 2 seconds to
display a directory with fewer than 60 entries.
 
 	Is this normal >>

Maybe, under NT.  Not under W95, not even with virus checker running.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[N8TM]

In a message dated 3/7/99 5:41:23 PM Pacific Standard Time,
treaves@y11a165.neo.rr.com writes:

<< 	When I execute this on my machine, a dual PII 266 with 192 meg memory & a
Seagate Cheeta 10,000rpm hard drive, with three other applications running
(Netscape, mail, a data conversion app), it takes a good 1.5 to 2 seconds to
display a directory with fewer than 60 entries.
 
 	Is this normal >>

Maybe, under NT.  Not under W95, not even with virus checker running.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Earnie Boyd]

---Timothy Reaves <treaves@y11a165.neo.rr.com> wrote:
>
> >>       When I execute this on my machine, a dual PII 266 with 192
meg
> >> memory & a Seagate Cheeta 10,000rpm hard drive, with three other
> >> applications running (Netscape, mail, a data conversion app), it
> >> takes a good 1.5 to 2 seconds to display a directory with fewer
than
> >> 60 entries.
> >> 
> >>       Is this normal?
> >
> >Just the first time, or every time?
> 
>      For a directory with 83 entries, the first display took 2.5
seconds. After that the time was 'normal'.  Dir under a DOS windows
has no perceptable delay.

If you add the color or F switches then the CYGWIN1.DLL has to
determine the type of file.  It will be opening every regular file
listed and reading a line from the file in order to determine the type
of the file.  You can imagine the overhead involved in this.
==
-                        \\||//
-------------------o0O0--Earnie--0O0o-------------------
--                earnie_boyd@yahoo.com               --
-- http://www.freeyellow.com/members5/gw32/index.html --
----------------------ooo0O--O0ooo----------------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Timothy Reaves]

>>       When I execute this on my machine, a dual PII 266 with 192 meg
>> memory & a Seagate Cheeta 10,000rpm hard drive, with three other
>> applications running (Netscape, mail, a data conversion app), it
>> takes a good 1.5 to 2 seconds to display a directory with fewer than
>> 60 entries.
>> 
>>       Is this normal?
>
>Just the first time, or every time?

     For a directory with 83 entries, the first display took 2.5 seconds. After that the time was 'normal'.  Dir under a DOS windows has no perceptable delay.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[DJ Delorie]

> 	When I execute this on my machine, a dual PII 266 with 192 meg
> memory & a Seagate Cheeta 10,000rpm hard drive, with three other
> applications running (Netscape, mail, a data conversion app), it
> takes a good 1.5 to 2 seconds to display a directory with fewer than
> 60 entries.
> 
> 	Is this normal?

Just the first time, or every time?

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Time taken for ls -la --color=yes

[Oelke, Dan]

> >If you add the color or F switches then the CYGWIN1.DLL has to
> >determine the type of file.  It will be opening every regular file
> >listed and reading a line from the file in order to determine the
type
> >of the file.  You can imagine the overhead involved in this.
> 
> No, I guess I can't, as bash under unix does not take this long, and
it would have to do the same thing.

Under Unix with a normal unix filesystem, the filesystem stores
attributes about each file.
With FAT filesystem there are no such attributes stored - cygwin has to
figure them out.
In particular, if a file is executable or not has be to guessed at by
reading 
the first few characters of the file.  So, cygwin has to open each file
to 
determine this which doesn't happen under unix.

Dan


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Timothy Reaves]

>If you add the color or F switches then the CYGWIN1.DLL has to
>determine the type of file.  It will be opening every regular file
>listed and reading a line from the file in order to determine the type
>of the file.  You can imagine the overhead involved in this.

No, I guess I can't, as bash under unix does not take this long, and it would have to do the same thing.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Sebastien Carpe]

Timothy Reaves wrote:
> 
> >If you add the color or F switches then the CYGWIN1.DLL has to
> >determine the type of file.  It will be opening every regular file
> >listed and reading a line from the file in order to determine the type
> >of the file.  You can imagine the overhead involved in this.
> 
> No, I guess I can't, as bash under unix does not take this long, and it would have to do the same thing.

And it does ... but the Unixes file systems stores a lot more informations that
the NTFS does, therefore open less files... On the other side, may be cygwin is
a bit slow at opening files.. 
On my side, running ls --color=yes on my NT box on a Unix directory through
samba seems to take forever on large directory (well, may be not htat much, but
i'm a pretty impatient guy regarding those things).

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Time taken for ls -la --color=yes

[Timothy Reaves]

	When I execute this on my machine, a dual PII 266 with 192 meg memory & a Seagate Cheeta 10,000rpm hard drive, with three other applications running (Netscape, mail, a data conversion app), it takes a good 1.5 to 2 seconds to display a directory with fewer than 60 entries.

	Is this normal

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Henry J. Cobb]

Doesn't LS take a lot of time to count the entries in every subdirectory it
encounters (even when it never lists them) just in order to fill out the
stat structures it then throws away?


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Fergus Henderson]

On 08-Mar-1999, Larry Hall (RFK Partners, Inc) <lhall@rfk.com> wrote:
> At 01:26 PM 3/8/99 -0500, Henry J. Cobb wrote:
> >Doesn't LS take a lot of time to count the entries in every subdirectory it
> >encounters (even when it never lists them) just in order to fill out the
> >stat structures it then throws away?

Yes, I believe so.  Well, it's actually the stat() DLL call that
is taking the time, rather than the code in the `ls' executable itself.

There's no simple way for the stat() DLL call to figure out whether
the caller will use the `st_nlinks' field in the stat struct.
So it has to assume that it will be used.  And implementing Unix
semantics for the st_nlinks field when stat() is called on a directory
requires counting the number of subdirectories in that directory.

I suppose ls could be patched to use something other than stat().

The ideal solution would be to patch the compiler to automatically
figure out whether the caller was using the st_nlinks field, and
if not, to automatically substitute say `__cheap_stat()' instead of
`stat()'.  However, this is not very feasible in a language like C...

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Larry Hall (RFK Partners, Inc)]

At 01:26 PM 3/8/99 -0500, Henry J. Cobb wrote:
>Doesn't LS take a lot of time to count the entries in every subdirectory it
>encounters (even when it never lists them) just in order to fill out the
>stat structures it then throws away?
>
>


Perhaps you can tell us, since you seem to imply that you know something
about the way ls works.  If it does work exactly as you suggest, then I
would say there is cause to be concerned about ls, although that comment
is based solely on yours and my incomplete understanding as to why ls would
do this.  Of course, if ls is doing this, it is outside the realm of
the cygwin DLL, since it only provides services to ls.  In this case, a
patch may need to be made to ls and, quite possibly, for cygwin only.
However, without more information, its hard to pursue the idea that either
ls or cygwin could be patched to make ls faster...


Larry Hall                             lhall@rfk.com
RFK Partners, Inc.                     (781) 239-1053
8 Grove Street                         (781) 239-1655
Wellesley, MA, 02482-7797              http://www.rfk.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Fergus Henderson]

On 08-Mar-1999, Larry Hall (RFK Partners, Inc) <lhall@rfk.com> wrote:
> At 01:26 PM 3/8/99 -0500, Henry J. Cobb wrote:
> >Doesn't LS take a lot of time to count the entries in every subdirectory it
> >encounters (even when it never lists them) just in order to fill out the
> >stat structures it then throws away?

Yes, I believe so.  Well, it's actually the stat() DLL call that
is taking the time, rather than the code in the `ls' executable itself.

There's no simple way for the stat() DLL call to figure out whether
the caller will use the `st_nlinks' field in the stat struct.
So it has to assume that it will be used.  And implementing Unix
semantics for the st_nlinks field when stat() is called on a directory
requires counting the number of subdirectories in that directory.

I suppose ls could be patched to use something other than stat().

The ideal solution would be to patch the compiler to automatically
figure out whether the caller was using the st_nlinks field, and
if not, to automatically substitute say `__cheap_stat()' instead of
`stat()'.  However, this is not very feasible in a language like C...

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Larry Hall (RFK Partners, Inc)]

At 01:26 PM 3/8/99 -0500, Henry J. Cobb wrote:
>Doesn't LS take a lot of time to count the entries in every subdirectory it
>encounters (even when it never lists them) just in order to fill out the
>stat structures it then throws away?
>
>


Perhaps you can tell us, since you seem to imply that you know something
about the way ls works.  If it does work exactly as you suggest, then I
would say there is cause to be concerned about ls, although that comment
is based solely on yours and my incomplete understanding as to why ls would
do this.  Of course, if ls is doing this, it is outside the realm of
the cygwin DLL, since it only provides services to ls.  In this case, a
patch may need to be made to ls and, quite possibly, for cygwin only.
However, without more information, its hard to pursue the idea that either
ls or cygwin could be patched to make ls faster...


Larry Hall                             lhall@rfk.com
RFK Partners, Inc.                     (781) 239-1053
8 Grove Street                         (781) 239-1655
Wellesley, MA, 02482-7797              http://www.rfk.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Henry J. Cobb]

Doesn't LS take a lot of time to count the entries in every subdirectory it
encounters (even when it never lists them) just in order to fill out the
stat structures it then throws away?


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Sebastien Carpe]

Timothy Reaves wrote:
> 
> >If you add the color or F switches then the CYGWIN1.DLL has to
> >determine the type of file.  It will be opening every regular file
> >listed and reading a line from the file in order to determine the type
> >of the file.  You can imagine the overhead involved in this.
> 
> No, I guess I can't, as bash under unix does not take this long, and it would have to do the same thing.

And it does ... but the Unixes file systems stores a lot more informations that
the NTFS does, therefore open less files... On the other side, may be cygwin is
a bit slow at opening files.. 
On my side, running ls --color=yes on my NT box on a Unix directory through
samba seems to take forever on large directory (well, may be not htat much, but
i'm a pretty impatient guy regarding those things).

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: Time taken for ls -la --color=yes

[Oelke, Dan]

> >If you add the color or F switches then the CYGWIN1.DLL has to
> >determine the type of file.  It will be opening every regular file
> >listed and reading a line from the file in order to determine the
type
> >of the file.  You can imagine the overhead involved in this.
> 
> No, I guess I can't, as bash under unix does not take this long, and
it would have to do the same thing.

Under Unix with a normal unix filesystem, the filesystem stores
attributes about each file.
With FAT filesystem there are no such attributes stored - cygwin has to
figure them out.
In particular, if a file is executable or not has be to guessed at by
reading 
the first few characters of the file.  So, cygwin has to open each file
to 
determine this which doesn't happen under unix.

Dan


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Timothy Reaves]

>If you add the color or F switches then the CYGWIN1.DLL has to
>determine the type of file.  It will be opening every regular file
>listed and reading a line from the file in order to determine the type
>of the file.  You can imagine the overhead involved in this.

No, I guess I can't, as bash under unix does not take this long, and it would have to do the same thing.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Earnie Boyd]

---Timothy Reaves <treaves@y11a165.neo.rr.com> wrote:
>
> >>       When I execute this on my machine, a dual PII 266 with 192
meg
> >> memory & a Seagate Cheeta 10,000rpm hard drive, with three other
> >> applications running (Netscape, mail, a data conversion app), it
> >> takes a good 1.5 to 2 seconds to display a directory with fewer
than
> >> 60 entries.
> >> 
> >>       Is this normal?
> >
> >Just the first time, or every time?
> 
>      For a directory with 83 entries, the first display took 2.5
seconds. After that the time was 'normal'.  Dir under a DOS windows
has no perceptable delay.

If you add the color or F switches then the CYGWIN1.DLL has to
determine the type of file.  It will be opening every regular file
listed and reading a line from the file in order to determine the type
of the file.  You can imagine the overhead involved in this.
==
-                        \\||//
-------------------o0O0--Earnie--0O0o-------------------
--                earnie_boyd@yahoo.com               --
-- http://www.freeyellow.com/members5/gw32/index.html --
----------------------ooo0O--O0ooo----------------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[Timothy Reaves]

>>       When I execute this on my machine, a dual PII 266 with 192 meg
>> memory & a Seagate Cheeta 10,000rpm hard drive, with three other
>> applications running (Netscape, mail, a data conversion app), it
>> takes a good 1.5 to 2 seconds to display a directory with fewer than
>> 60 entries.
>> 
>>       Is this normal?
>
>Just the first time, or every time?

     For a directory with 83 entries, the first display took 2.5 seconds. After that the time was 'normal'.  Dir under a DOS windows has no perceptable delay.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Time taken for ls -la --color=yes

[DJ Delorie]

> 	When I execute this on my machine, a dual PII 266 with 192 meg
> memory & a Seagate Cheeta 10,000rpm hard drive, with three other
> applications running (Netscape, mail, a data conversion app), it
> takes a good 1.5 to 2 seconds to display a directory with fewer than
> 60 entries.
> 
> 	Is this normal?

Just the first time, or every time?

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Time taken for ls -la --color=yes

[Timothy Reaves]

	When I execute this on my machine, a dual PII 266 with 192 meg memory & a Seagate Cheeta 10,000rpm hard drive, with three other applications running (Netscape, mail, a data conversion app), it takes a good 1.5 to 2 seconds to display a directory with fewer than 60 entries.

	Is this normal

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com