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.

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.

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.

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.

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.

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".

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.

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.

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.

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.

Read more

• All projects
• About the developer
• apoptotic — the Discord bot case study