mirror of
https://github.com/jarun/nnn.git
synced 2024-11-27 05:11:30 +00:00
Updated Performance (markdown)
parent
44cd982b05
commit
d6775df914
|
@ -4,7 +4,7 @@
|
|||
|
||||
## Optimization techniques
|
||||
|
||||
`nnn` uses highly optimized algorithms for performance. The significant factors are:
|
||||
#### `nnn` uses highly optimized algorithms for performance. The significant factors are:
|
||||
|
||||
- quicksort with pre-filters to sort by filename, time, size etc.
|
||||
- 0 fragmentation - no byte loss while storing file name of directory entries
|
||||
|
@ -24,6 +24,13 @@
|
|||
- `O3` level compiler optimization
|
||||
- 0-warning statically-analyzed code (forced `-Wall -Wextra -Werror` in CI)
|
||||
|
||||
#### Certain optimization techniques `nnn` development ignores:
|
||||
|
||||
- replace quicksort with a more aggressive algorithm by favoring space over time complexity (there was also an random load once and it's removed)
|
||||
- call non-standard platform-specific APIs like `getdents()`/`getdents64()` (the _Description_ section in the Linux man page starts with _These are not the interfaces you are interested in_); applies to `statx()` too
|
||||
- spend time on performance optimization over 10K entries in a dir as this is not the regular case and the performance with 10K files is quite good with the current implementation (in addition SSD and NVMe are the future)
|
||||
- use lazy/background load (`nnn` supports disk usage mode, sort orders and _nav-as-you-type_ as program options, so it needs to `stat` all files first for a _correct_ representation of the entries)
|
||||
|
||||
## Comparison
|
||||
|
||||
Stripped binary (or script) size & memory usage of `nnn` and some other popular FMs (which existed before `nnn`) while viewing a directory with 13.5K files (0 directories), sorted by size/du:
|
||||
|
|
Loading…
Reference in a new issue