3 ms·
The version available on apt is older. The performance numbers are from master. I am on a device with SSD now and `nnn` master consistently gives a better perfo
by apjana 7y ago
The version available on apt is older. The performance numbers are from master. I am on a device with SSD now and `nnn` master consistently gives a better performance in 3 runs.
Here are the numbers I see with $LS_COLORS set to:
ex=00:su=00:sg=00:ca=00:
nnn (still shows dir colors as it's designed to):
0.00user 0.00system 0:00.01elapsed 33%CPU (0avgtext+0avgdata 3420maxresident)k
0inputs+0outputs (0major+319minor)pagefaults 0swaps
ls (no colors):
0.00user 0.01system 0:00.02elapsed 60%CPU (0avgtext+0avgdata 3724maxresident)k
0inputs+0outputs (0major+297minor)pagefaults 0swaps
And going deeper, with the same $LS_COLORS, see the difference in the number of calls (no wonder `nnn` outperforms `ls`):
$ time strace -c /usr/local/bin/nnn /usr/bin | wc -l
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
82.55 0.004592 2 1988 newfstatat
8.47 0.000471 118 4 getdents
2.82 0.000157 3 58 1 stat
1.89 0.000105 105 1 inotify_add_watch
1.64 0.000091 9 10 brk
1.33 0.000074 5 15 close
0.23 0.000013 1 14 openat
0.18 0.000010 3 4 write
0.18 0.000010 0 22 2 ioctl
0.13 0.000007 0 15 fstat
0.13 0.000007 1 14 mmap
0.13 0.000007 7 1 inotify_rm_watch
0.11 0.000006 1 8 read
0.11 0.000006 6 1 1 unlink
0.07 0.000004 4 1 sysinfo
0.05 0.000003 3 1 lseek
0.00 0.000000 0 2 lstat
0.00 0.000000 0 10 mprotect
0.00 0.000000 0 1 munmap
0.00 0.000000 0 9 rt_sigaction
0.00 0.000000 0 9 7 access
0.00 0.000000 0 1 execve
0.00 0.000000 0 1 arch_prctl
0.00 0.000000 0 1 inotify_init1
------ ----------- ----------- --------- --------- ----------------
100.00 0.005563 2191 11 total
0.03user 0.01system 0:00.06elapsed 74%CPU (0avgtext+0avgdata 3424maxresident)k
2968inputs+0outputs (7major+541minor)pagefaults 0swaps
0
$ time strace -c ls -l /usr/bin | wc -l
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
32.03 0.004882 2 1989 lstat
30.42 0.004636 2 1989 1989 lgetxattr
22.45 0.003421 2 1548 1548 getxattr
6.57 0.001002 2 442 readlink
6.15 0.000938 235 4 getdents
0.45 0.000068 2 33 5 openat
0.43 0.000066 6 11 munmap
0.31 0.000047 1 34 close
0.30 0.000045 1 40 mmap
0.26 0.000040 2 17 lseek
0.20 0.000031 1 30 fstat
0.10 0.000015 4 4 4 connect
0.09 0.000014 3 5 brk
0.07 0.000011 3 4 socket
0.07 0.000010 0 31 write
0.06 0.000009 9 1 mremap
0.03 0.000005 0 17 read
0.00 0.000000 0 20 mprotect
0.00 0.000000 0 2 rt_sigaction
0.00 0.000000 0 1 rt_sigprocmask
0.00 0.000000 0 2 2 ioctl
0.00 0.000000 0 12 12 access
0.00 0.000000 0 1 execve
0.00 0.000000 0 2 2 statfs
0.00 0.000000 0 1 arch_prctl
0.00 0.000000 0 1 futex
0.00 0.000000 0 1 set_tid_address
0.00 0.000000 0 1 set_robust_list
0.00 0.000000 0 1 prlimit64
------ ----------- ----------- --------- --------- ----------------
100.00 0.015240 6244 3562 total
0.04user 0.06system 0:00.09elapsed 114%CPU (0avgtext+0avgdata 3676maxresident)k
0inputs+0outputs (0major+521minor)pagefaults 0swaps
1989
- eindiran 7y agoVery cool. Do you know what the timeline is for getting the contents of master into the version packaged for apt? On the topic of `ls` making many more syscalls than `nnn`, its interesting that `nnn` is using the `newfstatat` syscall. Is that capturing the information that the `lstat`, `lgetxattr`, and `getxattr` syscalls are getting for `ls`? If so, will that potentially limit this speed up to architectures that make use of the newer `newfstatat` syscall?
- apjana 7y agoTo get the last release: https://github.com/jarun/nnn/issues/217#issuecomment-469226327 https://github.com/jarun/nnn/issues/217#issuecomment-4692263... I am not sure when I will make the next release. I need to make sure it's stable enough through testing and that would take a while. > newfstatat Don't think so. For the basic info ls/nnn shows in the list mode, extended attributes are not strictly required.