GNU bug report logs - #35531
problem with ls in coreutils

Previous Next

Full log

Message #14 received at 35531 <at> debbugs.gnu.org (full text, mbox):

From: Viktors Berstis <cugnujm <at> berstis.com>
To: 35531 <at> debbugs.gnu.org
Cc: kdudka <at> redhat.com
Subject: Re: bug#35531: problem with ls in coreutils
Date: Thu, 2 May 2019 16:12:52 -0700

My machine has 64GB of ram, 6 core 3.5ghz processor and fast disks.
The directory in question has 57,600 files in it with a total size of 
about 47gb.
On a freshly booted machine (nothing cached),  "dir /on dirname | wc" 
takes about 6 seconds.  The second time it takes about 2 seconds.
On a freshly booted machine, "ls -U -1 dirname | wc" takes 5 minutes 48 
seconds!  A second time it is about a minute less.
ls might be doing something akin to opening every file.  If I run a 
program to actually open and read every file in that directory, the 
system seems to cache it all in ram.  Then the ls takes only about 11 
seconds.

- Viktors Berstis

Kamil Dudka wrote:
> On Thursday, May 2, 2019 12:03:31 AM CEST Viktors Berstis wrote:
>> When running "ls" or "ls -U" on a windows directory containing 50000
>> files, ls takes forever.  Something seems to be highly inefficient in there.
> Could you please try it with ls -U -1?
>
> Kamil
>
>> This is for the 64 bit version build 4/20/2005 11:41AM.  The exe size is
>> 180736 bytes.
>>
>> Thanks.
>>
>> - Viktors Berstis
>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.