itree

itree is a fast, iterative directory tree viewer.

On a benchmark containing 1,089 directories and 8,192 files, itree was 2.13× faster than tree 2.3.2, while producing identical output.

itree  █████████▍            19.906 ms
tree   ████████████████████   42.461 ms

Why it is fast

• Keeps compact entries in the traversal stack instead of retaining std::fs::DirEntry.
• Uses in-place unstable sorting.
• Detects whether stdout is a terminal: terminal output remains interactive, while redirected output uses block buffering.

Iterative traversal

itree uses an explicit, heap-allocated work stack instead of recursive function calls. This is a robustness choice: traversal depth does not consume the thread's call stack, so deeply nested directory trees cannot cause a call stack overflow.

An otherwise equivalent recursive prototype performed within 1% of the iterative implementation across balanced, wide, and deeply nested test trees. Iterative traversal is therefore not presented as a source of the benchmarked speedup over tree.

Usage

Build an optimized binary:

cargo build --release

Display a directory tree:

./target/release/itree .

Usage: itree [OPTIONS] <PATH>

Arguments:
  <PATH>

Options:
  -a, --show-hidden
  -L, --max-depth <DEPTH>
      --charset <CHARSET>  [default: UTF-8] [possible values: UTF-8, ASCII]
  -h, --help               Print help
  -V, --version            Print version

For example:

./target/release/itree --show-hidden --max-depth 2 --charset ASCII .

Benchmark

Implementation	Median	Mean	p95	Relative speed
itree 0.1.0	19.906 ms	19.839 ms	20.334 ms	2.13×
tree 2.3.2	42.461 ms	42.434 ms	43.141 ms	1.00×

Benchmark conditions:

• Apple M2 MacBook Air, 8 CPU cores, 16 GB RAM
• macOS Darwin 25.5.0
• itree built with cargo build --release using Rust 1.96.0
• tree 2.3.2 built with -O3 -DNDEBUG
• Synthetic tree containing 1,089 directories and 8,192 empty files
• 200 measured runs per implementation after 15 warm-up runs
• Execution order randomized to reduce ordering bias
• Standard output redirected to /dev/null
• Warm filesystem and CPU caches

Both implementations generated 311,933 bytes across 9,283 lines. Their output was compared byte-for-byte and contained no differences.

This benchmark measures warm-cache traversal, sorting, formatting, and output overhead. Results will vary with hardware, filesystem, directory shape, cache state, and file names.