Your message dated Sun, 13 Nov 2005 13:37:11 -0500
with message-id <[EMAIL PROTECTED]>
and subject line ls -l is slow
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 17 Nov 2001 16:25:32 +0000
>From [EMAIL PROTECTED] Sat Nov 17 10:25:32 2001
Return-path: <[EMAIL PROTECTED]>
Received: from 90-madr-x23.libre.retevision.es (caballero.localnet)
[62.83.14.90]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 1658Ha-0002cM-00; Sat, 17 Nov 2001 10:25:31 -0600
Received: from jl by caballero.localnet with local (Exim 3.32 #1 (Debian))
id 1658Ge-0002sT-00
for <[EMAIL PROTECTED]>; Sat, 17 Nov 2001 17:24:32 +0100
Date: Sat, 17 Nov 2001 17:24:32 +0100
To: [EMAIL PROTECTED]
Subject: fileutils: ls -l is significantly slower on woody than potato
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.23i
From: =?iso-8859-1?Q?Jos=E9_Luis_Gonz=E1lez_Gonz=E1lez?= <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Package: fileutils
Version: 4.1-7
Severity: wishlist
ls -l is about four times slower on woody than potato. This is very
annoying. May this be caused by glibc 2.2?
Those are the times for woody:
On an i486 (66Mhz) with 16 Mbytes (no other process running, plenty of
free memory:
~$ time ls -l
total 9
-rw-r----- 1 jlg jlg 401 oct 25 18:25 NOTAS
drwx--S--- 2 jlg jlg 1024 nov 2 14:45 Mail
drwxr-xr-x 2 jlg jlg 1024 nov 14 01:47 bin
drwx------ 3 jlg jlg 1024 oct 18 14:50 eui
-rw-r--r-- 1 jlg jlg 425 jul 28 01:48 operators
drwxr-sr-x 3 jlg jlg 1024 oct 23 23:19 public_html
drwxr-sr-x 2 jlg jlg 1024 nov 16 10:52 stdc
drwx------ 4 jlg jlg 1024 oct 15 17:16 trabajo
drwxr-sr-x 3 jlg jlg 1024 oct 26 17:52 uplog
real 0m0.098s
user 0m0.050s
sys 0m0.030s
~$ time ls
NOTAS Mail bin eui operators public_html stdc trabajo uplog
real 0m0.054s
user 0m0.040s
sys 0m0.010s
The directory has lots of hidden files, so I have not used -a.
Those are the times for woody:
On an i486 (66Mhz) with 32 Mbytes (no other process running, plenty of free
memory):
~$ time ls -al
total 20
drwxr-sr-x 5 jl jl 1024 nov 16 15:40 .
drwxrwsr-x 4 root staff 1024 mar 31 2001 ..
-rw------- 1 jl jl 7033 nov 17 00:18 .bash_history
-rw-r--r-- 1 jl jl 117 oct 10 18:29 .bash_logout
-rw-r--r-- 1 jl jl 511 nov 17 12:59 .bash_profile
-rw-r--r-- 1 jl jl 1720 nov 17 12:57 .bashrc
drwxr-sr-x 2 jl jl 1024 nov 3 13:57 .icewm
drwx------ 2 jl jl 1024 nov 14 19:28 .links
drwxr-sr-x 2 jl jl 1024 oct 10 16:20 .ssh
-rw------- 1 jl jl 639 nov 7 18:53 .viminfo
-rw------- 1 jl jl 100 sep 24 12:36 .Xauthority
-rw-r--r-- 1 jl jl 260 jun 3 17:09 .Xresources
-rw------- 1 jl jl 0 nov 16 15:40 .xsession-errors
-rw-r--r-- 1 jl jl 760 ago 11 11:31 .zilerc
real 0m0.443s
user 0m0.330s
sys 0m0.110s
~$ time ls -a
. .bash_logout .icewm .viminfo .xsession-errors
.. .bash_profile .links .Xauthority .zilerc
.bash_history .bashrc .ssh .Xresources
real 0m0.127s
user 0m0.060s
sys 0m0.060s
On an Intel Pentium (133Mhz) with 64 Mbytes (no other process running, plenty
of free memory):
~$ mkdir empty
~$ cd empty
~/empty$ time ls -a
. ..
real 0m0.042s
user 0m0.020s
sys 0m0.030s
~/empty$ time ls -al
total 8
drwxr-sr-x 2 jl jl 4096 nov 17 13:41 .
drwxr-sr-x 27 jl jl 4096 nov 17 13:41 ..
real 0m0.188s
user 0m0.170s
sys 0m0.020s
This may be annoying on slow systems (like that i486 I used to measure time).
And how does it take 0.188s on a Pentium machine to list an empty directory?
It used to be much less.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux caballero 2.4.14 #1 mié nov 14 19:56:24 CET 2001 i586
unknown
Versions of the packages fileutils depends on:
ii libc6 2.2.4-5 GNU C Library: Shared libraries and Timezone
---------------------------------------
Received: (at 119973-done) by bugs.debian.org; 13 Nov 2005 18:37:13 +0000
>From [EMAIL PROTECTED] Sun Nov 13 10:37:13 2005
Return-path: <[EMAIL PROTECTED]>
Received: from vms048pub.verizon.net ([206.46.252.48])
by spohr.debian.org with esmtp (Exim 4.50)
id 1EbMj3-0006h9-GU
for [EMAIL PROTECTED]; Sun, 13 Nov 2005 10:37:13 -0800
Received: from osgiliath.mathom.us ([70.108.64.202])
by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep
9 2005)) with ESMTPA id <[EMAIL PROTECTED]> for
[EMAIL PROTECTED]; Sun, 13 Nov 2005 12:37:13 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
by osgiliath.mathom.us (Postfix) with ESMTP id 2B857606646 for
<[EMAIL PROTECTED]>; Sun, 13 Nov 2005 13:37:12 -0500 (EST)
Received: from osgiliath.mathom.us ([127.0.0.1])
by localhost (osgiliath [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id 20634-01-5 for <[EMAIL PROTECTED]>; Sun,
13 Nov 2005 13:37:12 -0500 (EST)
Received: by osgiliath.mathom.us (Postfix, from userid 1000)
id 05EFB60049B; Sun, 13 Nov 2005 13:37:12 -0500 (EST)
Date: Sun, 13 Nov 2005 13:37:11 -0500
From: Michael Stone <[EMAIL PROTECTED]>
Subject: ls -l is slow
To: [EMAIL PROTECTED]
Message-id: <[EMAIL PROTECTED]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
X-Pgp-Fingerprint: 53 FF 38 00 E7 DD 0A 9C 84 52 84 C5 EE DF 7C 88
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mathom.us
User-Agent: Mutt/1.5.11
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-0.5 required=4.0 tests=BAYES_30 autolearn=no
version=2.60-bugs.debian.org_2005_01_02
empty> time ls -al
total 4
drwxrwxr-x 2 mstone mstone 6 2005-11-13 13:34 .
drwxrwxr-x 7 mstone mstone 4096 2005-11-13 13:34 ..
0.006u 0.007s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
Well, ls -l is a lot faster than the examples given, so maybe it's sped
up. OTOH, it might just be that I have a faster machine. At any rate
it's water under the bridge and I don't expect ls to dramatically change
its speed at this point--it certainly does a lot more behind the scenes
than it did on potato.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
