Overview
What Dendrite is
Dendrite is a Windows-native desktop application written in Rust, built for one
specific job: making sense of a full disk on a real Windows machine. It scans
mounted drives — preferably through fast low-level NTFS mechanisms — builds a
memory-optimized filesystem tree, derives searchable, sortable visual views from
that tree, and layers analysis features on top: category breakdowns, largest
files and folders, cleanup suggestions, exports, folder comparison, usage
history, and live update tracking.
The whole architecture cleanly separates orchestration, core data and processing,
and UI rendering, with nearly all expensive work happening asynchronously through
channel-based background tasks. The result is a tool that stays responsive while
scanning a multi-terabyte volume, keeps retained memory low even at scale, and
treats Windows as a first-class target rather than a portability afterthought.
Why It Exists
The problem space
Disk-usage analyzers are not new. The classic ones either freeze on the first
big folder, hold the entire tree in RAM with one allocation per node and grind
a system to a halt at scale, or treat Windows as a generic POSIX surface and
miss out on everything NTFS makes possible. Dendrite is built around the opposite
set of priorities:
- Responsiveness first. The UI thread does no I/O and almost no work. Scanning, parsing, and aggregation happen on background tasks that report progress over channels.
- Low retained memory. The filesystem tree is laid out for compactness, not pointer-chasing convenience, so a multi-million-entry scan stays well-behaved on consumer hardware.
- Windows-specific where it counts. Where the operating system gives a faster path, Dendrite uses it.
Scanning
NTFS-preferred scan path
On a typical Windows volume, Dendrite prefers fast low-level NTFS mechanisms over
the generic per-file enumeration that most cross-platform tools rely on. NTFS
keeps a structured record of every file on the volume, and reading that record
in bulk is dramatically faster than walking the directory tree one entry at a
time — particularly on volumes with millions of small files where the per-call
overhead dominates.
For best results, Dendrite should be run with administrator privileges:
the NTFS-preferred path requires permissions that a normal user account does
not always have, and without those permissions Dendrite quietly falls back to
the slower per-file path. The application makes that fallback explicit in the
UI rather than silently underperforming.
Data Model
The memory-optimized filesystem tree
Once a volume is scanned, every file and folder lives in a single in-memory
structure: the filesystem tree. Naively, that's a tree of HashMaps
— easy to write, painful at scale, because every node carries pointer overhead
and allocator metadata that adds up fast across millions of entries.
Dendrite trades that easy layout for a denser representation: child relationships
are encoded as indices into flat arenas rather than heap pointers, hot fields
are packed close together, and the tree owns its own string storage rather than
fragmenting into per-node allocations. The practical effect is that a fully
populated multi-terabyte volume scan stays inside a budget that real laptops
and workstations can spare, instead of pushing the process toward swap.
Architecture
Orchestration · Core · UI
The codebase is split into three layers:
- Orchestration — wires together scans, refresh tasks, exports, and saved sessions; owns the long-lived state machine of "what is the app currently doing".
- Core data and processing — owns the filesystem tree, the scan implementation, the analysis routines (categorization, largest-N, comparisons, history diffing), and the persistence format. None of this code knows the UI exists.
- UI rendering — turns the current state into a window: trees, charts, progress, search results. It only reads from the model layer; it never blocks on I/O.
The boundaries are enforced by what each module is allowed to import. The UI
layer cannot reach into scan internals; the core layer cannot reach into widget
code. That keeps each piece testable on its own, and makes it possible to swap
the rendering layer in the future without rewriting the engine.
Async
Channel-based background tasks
Nearly all expensive work happens off the UI thread. Scans, refreshes, exports,
and folder comparisons are spawned as background tasks that publish progress and
results over channels. The UI subscribes to those channels and re-renders when
new data arrives — there is no blocking call in any redraw path. That is the
single biggest reason the application stays smooth even when a scan is in full
swing.
The same pattern handles cancellation: stopping a scan is just dropping a
handle, and the background task observes that and tears itself down cleanly.
No "please wait while we finish doing the thing you asked us to stop doing".
Features
What you can actually do with it
- Searchable, sortable views derived from the filesystem tree — find a folder by partial name and sort by size, count, modified time, or category without a re-scan.
- Category breakdowns — videos, archives, installers, source code, build artefacts, and so on. Categories are configurable.
- Largest files and folders — top-N reports across the whole volume or a subtree.
- Cleanup suggestions — heuristics that surface plausible deletion candidates (build outputs, old downloads, duplicates) without ever deleting anything itself; the user is always in the loop.
- Exports — push the current view or the full tree out to a file format you can read later or feed into another tool.
- Folder comparison — diff two folders or two snapshots of the same folder and see exactly what changed.
- Usage history — track how a volume has filled up over time using saved snapshots.
- Live update tracking — when a scan is open, ongoing changes to the filesystem are reflected in the view rather than going stale.
Performance
Responsiveness and memory
Two metrics matter most for an analyzer of this kind: how long the user waits
for a scan to feel useful, and how much memory the application is holding while
it shows that scan. Dendrite optimizes both:
- Scans report incremental results — the UI is usable long before the scan completes.
- The tree representation aims for the lowest practical bytes-per-entry without sacrificing the lookup paths that interactive views need.
- Background tasks coalesce updates so the UI never sees a burst of redraw events even on a fast scan.
Privileges
Why administrator?
Dendrite assumes administrator privileges for best results. The NTFS-preferred
scan path needs them; reading certain protected directories (Windows-owned
folders, other users' profiles) needs them; and writing snapshot history into
a shared location needs them. Run without admin, the app still works, but it
falls back to the slower path and skips folders it cannot read — and it tells
you so.
Roadmap
Where it's going
The current focus is on making the analysis layer richer: better categorization
rules, a more aggressive duplicate-detection pass that survives renames, and
smarter cleanup suggestions that explain themselves rather than asking the user
to take heuristics on faith. The architecture splits leave the door open for a
headless mode (scan + export from the command line) and for plug-in analyses
written against the core layer.
None of these will compromise the responsiveness or low-memory targets — those
are non-negotiable, because they are the actual reason Dendrite exists.
Related
Read more