4 ms·

I just downloaded `nnn` from apt and I am not seeing this performance at all. `ls` is blazingly faster than `nnn` on this machine. I am seeing a speedup over `r

I just downloaded `nnn` from apt and I am not seeing this performance at all. `ls` is blazingly faster than `nnn` on this machine. I am seeing a speedup over `ranger`, but both are taking quite a while for a directory with 196388 files in it. time /usr/bin/nnn -S /local /usr/bin/nnn -S /local 0.04s user 0.36s system 15% cpu 2.503 total time /usr/bin/ranger /local /usr/bin/ranger /local 0.31s user 0.02s system 12% cpu 2.667 total time /bin/ls /local /bin/ls /local 0.00s user 0.00s system 86% cpu 0.002 total Perhaps this is related to the `$LS_COLORS` environment variable, as discussed in a few other comments? It is set on this machine. echo $LS_COLORS no=00:fi=00:di=34:ow=34;40:ln=35:...<many more entries>...:*.sqlite=34:

deleted 7y ago
[deleted]
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 ago
  Very 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 ago
    To 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.

deleted 7y ago

[deleted]

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 ago
Very 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 ago
  To 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.