Oxide v0.6.0 vs WizTree 4.32 Benchmarks

Transparent, repeatable scan measurements captured on Windows 11. These engineering benchmarks reflect empirical telemetry recorded on Oxide release v0.6.0 on the core scanning engine.

Test Environment & Methodology

All measurements were captured on a dedicated Windows 11 test machine equipped with an AMD Ryzen 7 5800H processor and an internal NVMe solid-state drive. The target volume was a production system drive (C:) containing 3,071,570 entries indexed across 5,429,248 raw MFT records.

Telemetry was recorded continuously at 50 ms intervals by an automated Python benchmark harness (benchmark_oxide_vs_wiztree.py). The harness tracks process working set (physical RAM), private commit charge, and wall-clock phase transitions from launch to fully settled user interaction. Both applications were executed with elevated administrator privileges to permit direct NTFS volume access.

1. Speed & Latency Breakdown

Oxide achieves a fully responsive, interactive treemap in 6.34 seconds from process start. The Rust core completes disk parsing and data aggregation in 5.38 seconds, after which the user interface stabilizes.

Oxide backend internal phase timing for 3,071,570 nodes:

• Raw MFT record parse: 1.32 s
• Packed arena ingestion: 0.27 s
• Parent-child hierarchy link: 0.05 s
• Linear depth-first size aggregation: 0.17 s
• Largest files list compilation: 0.05 s
• Total backend engine duration: 5.38 s

2. RAM Footprint Over Time (Working Set)

Physical working set memory was tracked across three distinct lifecycle phases: idle before scan, peak usage during active parsing, and settled memory once the treemap is interactive.

3. Private Commit (Exclusive Memory Allocated)

Private commit reflects memory exclusively claimed by each process from the operating system page file:

Architectural Analysis: Fixed Baseline vs O(N) Scaling

The contrast in memory efficiency stems directly from differences in memory layout:

• Rust Flat Arena (O(N) Compact Scaling): Oxide stores each file entry in a packed struct (FileEntry) with 32-bit string intern offsets. At settled state, 3.07 million nodes occupy only 206.0 MB of memory in the backend engine, averaging ~67.1 bytes per node. By comparison, WizTree uses Delphi VCL object allocations costing 1,620.4 MB, or ~527.5 bytes per node (7.9x higher per-node overhead).
• WebView2 Fixed Baseline: WizTree uses a legacy native Win32 user interface that starts at an idle baseline of 88.8 MB. Oxide uses modern Chromium WebView2, which incurs a fixed initialization footprint of approximately 340 to 360 MB regardless of disk size.
• The Net Result: Despite the fixed WebView2 runtime cost, Oxide's high tree compaction means that on typical consumer and workstation drives (3 million or more files), the complete Oxide application saves over 1,040 MB of RAM compared to WizTree while reaching an interactive state 3.0x faster.

Guidelines for Repeatable Verification

When reproducing or verifying these benchmarks on your own system, maintain the following controls:

• Scan the exact same physical drive partition without modifying files between comparisons.
• Note whether the drive cache was warm from a prior scan or cold from a system reboot.
• Ensure both tools run with administrator privileges to utilize direct NTFS MFT access. Standard user mode forces standard Win32 directory traversal, which is significantly slower for both tools.
• Capture both total scan duration and settled working set memory once user interface rendering is complete.