You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* ls: Remove allocations by eliminating collect/clones
* ls: Introduce PathData structure
- PathData will hold Path related metadata / strings that are required
frequently in subsequent functions
- All data is precomputed and cached and subsequent functions just
use cached data
* ls: Cache more data related to paths
- Cache filename and sort by filename instead of full path
- Cache uid->usr and gid->grp mappings
https://github.com/uutils/coreutils/pull/2099/files
* ls: Add BENCHMARKING.md
* ls: Document PathData structure
* tests/ls: Add testcase for error paths with width option
* ls: Fix unused import warning
cached will be only used for unix currently as current use of
caching gid/uid mappings is only relevant on unix
* ls: Suggest checking syscall count in BENCHMARKING.md
* ls: Remove mentions of sort in BENCHMARKING.md
* ls: Remove dependency on cached
Implement caching using HashMap and lazy_static
* ls: Fix MSRV error related to map_or
Rust 1.40 did not support map_or for result types
ls majorly involves fetching a lot of details (depending upon what details are requested, eg. time/date, inode details, etc) for each path using system calls. Ideally, any system call should be done only once for each of the paths - not adhering to this principle leads to a lot of system call overhead multiplying and bubbling up, especially for recursive ls, therefore it is important to always benchmark multiple scenarios.
4
+
This is an overwiew over what was benchmarked, and if you make changes to `ls`, you are encouraged to check
5
+
how performance was affected for the workloads listed below. Feel free to add other workloads to the
6
+
list that we should improve / make sure not to regress.
7
+
8
+
Run `cargo build --release` before benchmarking after you make a change!
9
+
10
+
## Simple recursive ls
11
+
12
+
- Get a large tree, for example linux kernel source tree.
13
+
- Benchmark simple recursive ls with hyperfine: `hyperfine --warmup 2 "target/release/coreutils ls -R tree > /dev/null"`.
14
+
15
+
## Recursive ls with all and long options
16
+
17
+
- Same tree as above
18
+
- Benchmark recursive ls with -al -R options with hyperfine: `hyperfine --warmup 2 "target/release/coreutils ls -al -R tree > /dev/null"`.
19
+
20
+
## Comparing with GNU ls
21
+
22
+
Hyperfine accepts multiple commands to run and will compare them. To compare performance with GNU ls
23
+
duplicate the string you passed to hyperfine but remove the `target/release/coreutils` bit from it.
24
+
25
+
Example: `hyperfine --warmup 2 "target/release/coreutils ls -al -R tree > /dev/null"` becomes
26
+
`hyperfine --warmup 2 "target/release/coreutils ls -al -R tree > /dev/null" "ls -al -R tree > /dev/null"`
27
+
(This assumes GNU ls is installed as `ls`)
28
+
29
+
This can also be used to compare with version of ls built before your changes to ensure your change does not regress this
30
+
31
+
## Checking system call count
32
+
33
+
- Another thing to look at would be system calls count using strace (on linux) or equivalent on other operating systems.
34
+
- Example: `strace -c target/release/coreutils ls -al -R tree`
0 commit comments