If you do a significant amount of programming, you'll probably end up with
build artifacts scattered about. sn is a tool to help you find those
artifacts.
sn is also a replacement for du. It has nicer
output, saner commands and defaults, and it even runs faster on big directories
thanks to multithreading.
Enter the following in a command prompt:
curl -LSfs https://japaric.github.io/trust/install.sh | sh -s -- --git vmchale/tin-summer
If the script doesn't work for you, you can download a binary from the releases page.
If your platform doesn't have binaries, or you just want to build from source, get cargo. Then:
$ cargo install tin-summerMake sure you are on nightly; otherwise
$ rustup run nightly cargo install tin-summerTo list directory and file sizes for the current directory:
$ sn f
To get a list of directory sizes concurrently, excluding version control:
$ sn p --exclude '\.git|\.pijul|_darcs|\.hg'
To get a sorted list of the 12 biggest directories in $DIR:
$ sn sort $DIR -n12
To search current directory for directories with build artifacts:
$ sn arTo look for artifacts or directories containing artifacts that occupy more than 200MB of disk space:
$ sn ar -t200MTo turn off colorized output:
export CLICOLOR=0- Reads disk usage, not just file sizes
- Optionally dereferences symlinks
- Slightly faster on small directories
- Stable and well-supported
- Faster on large directories
- Uses regex for exclusions, making it
dramatically faster than
duwhen used with the--excludeflag. - Defaults to human-readable output
- Colorized output
- Nicer help via clap
- Provides sorted output
- Finds build artifacts
- Reads file sizes, not disk usage
- Extensible in Rust
| Directory Size | Tool | Command | Time |
|---|---|---|---|
| 600MB | sn | sn p |
60.74 ms |
| 600MB | sn | sn d |
99.92 ms |
| 600MB | du | du -hacd2 |
88.28 ms |
| 4GB | sn | sn p |
185.2 ms |
| 4GB | sn | sn d |
271.9 ms |
| 4GB | du | du -hacd2 |
195.5 ms |
| 700MB | sn | sn p |
91.05 ms |
| 700MB | sn | sn d |
176.3 ms |
| 700MB | du | du -hacd2 |
153.8 ms |
| 7MB | sn | sn p |
19.48 ms |
| 7MB | sn | sn d |
12.72 ms |
| 7MB | du | du -hacd2 |
10.13 ms |
These commands are all essentially equivalent in function, except that sn p
may use more threads than sn a or du. Results were obtained using Gabriel Gonzalez's bench
tool. You can see pretty criterion graphs
here or
here.
In summary: yes, sn actually is faster on larger directories, but it is also
slower on small ones. I'm hoping to make it faster in the future; the current
naïve concurrency model has obvious directions for improvement.
Currently, sn looks for files that either have an extension associated with
build artifacts, or executable files that are ignored by version control. It also looks for "build
directories", like .stack-work, elm-stuff, etc. and if it finds a
configuration file like tweet-hs.cabal, it considers all their
contents to be build artifacts.
The following is a list of languages sn artifacts has been tested with.
The intent is to support basically anything, so feel free to open a PR or start an issue.
- Haskell (incl. GHCJS)
- Rust
- Julia
- Python
- Elm
- Nim
- Vimscript
- TeX
- Idris
- FORTRAN
- Ruby
- C
sn can clean up your artifacts for you, but only for the above-indicated
languages. It is still experimental, but it has been tested and should not
delete unwanted files (though it may not clean everything it should).
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent