bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: suggested feature/patch for ls: -P TYPES, --select-file-type=TYPES


From: Moreno Baricevic
Subject: Re: suggested feature/patch for ls: -P TYPES, --select-file-type=TYPES
Date: 16 Dec 2005 20:08:52 +0100

On Fri, 2005-12-16 at 18:34, Paul Eggert wrote:
> Moreno Baricevic <address@hidden> writes:
> 
> > My point is that on a populated directory (e.g. /dev on 2.4), filtering
> > file types inside ls is faster than doing it externally by parsing a
> > huge output.
> 
> How much faster?  For example, what is the performance of your
> modified version of ls with the -P option, compared to the following
> ways of solving the problem without adding options?
> 
> time sh -c 'ls -lR -P c /dev' >/tmp/baz
> time sh -c 'ls -lR /dev | grep "^c"' >/tmp/foo
> time sh -c 'ls -ld $(find /dev -type c -print)' >/tmp/bar


With d_type on ext3 (logs reported below), it seems to be ~5 times
faster than ls+grep and ~2 times faster than find+ls. For symlinks it's
12-16 times faster than ls+grep, only 2-3 times faster than find+ls.

Without d_type on reiserfs (not reported below), it's quite similar to
find+ls (.094s vs .114s), only 2-3 times faster than ls+grep (.261s).
For symlinks it's 4 times faster than ls+grep (.063s vs .255s) and a bit
slower than find+ls (.045s).

Anyway, I know that .03s instead of .06s (or .15s) is not a big deal,
thus I guess it's not enough to add an option.

Thanks for your reviews.

Have a nice week-end.

Moreno


#==============================
# PC1
real    0m0.051s
user    0m0.030s
sys     0m0.020s

real    0m0.238s
user    0m0.150s
sys     0m0.090s

real    0m0.092s
user    0m0.080s
sys     0m0.010s
0.04user 0.01system 0:00.05elapsed 100%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (436major+221minor)pagefaults 0swaps
0.19user 0.05system 0:00.23elapsed 101%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (590major+602minor)pagefaults 0swaps
0.06user 0.03system 0:00.09elapsed 100%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (574major+413minor)pagefaults 0swaps

real    0m0.014s
user    0m0.000s
sys     0m0.010s

real    0m0.230s
user    0m0.210s
sys     0m0.020s

real    0m0.041s
user    0m0.010s
sys     0m0.030s
0.00user 0.01system 0:00.01elapsed 76%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (436major+69minor)pagefaults 0swaps
0.20user 0.03system 0:00.23elapsed 99%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (590major+602minor)pagefaults 0swaps
0.00user 0.04system 0:00.04elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (574major+162minor)pagefaults 0swaps
#==============================
# PC2

real    0m0.038s
user    0m0.030s
sys     0m0.010s

real    0m0.158s
user    0m0.140s
sys     0m0.020s

real    0m0.060s
user    0m0.040s
sys     0m0.020s
0.03user 0.01system 0:00.03elapsed 108%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (457major+104minor)pagefaults 0swaps
0.15user 0.01system 0:00.15elapsed 101%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (595major+278minor)pagefaults 0swaps
0.04user 0.02system 0:00.05elapsed 101%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (567major+199minor)pagefaults 0swaps

real    0m0.012s
user    0m0.010s
sys     0m0.000s

real    0m0.154s
user    0m0.140s
sys     0m0.020s

real    0m0.029s
user    0m0.020s
sys     0m0.010s
0.01user 0.00system 0:00.01elapsed 90%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (449major+52minor)pagefaults 0swaps
0.13user 0.02system 0:00.15elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (595major+278minor)pagefaults 0swaps
0.01user 0.02system 0:00.02elapsed 107%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (559major+114minor)pagefaults 0swaps
#==============================


Attachment: SPEED_TEST
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]