File Read Performance Benchmark

A comprehensive C++20 benchmark suite for analyzing sequential vs sparse file reading performance, with a focus on "time to end" metrics for large files.

Overview

This benchmark suite was created to test the hypothesis that sparse file reading can reach the end of large files faster than sequential reading, despite having lower overall data throughput. The results confirm this hypothesis with dramatic performance improvements for file scanning operations.

System Specifications

Test Environment:

• CPU: AMD Ryzen 9 5900X
• RAM: 128GB DDR4 @ 1648MHz
• Storage: Samsung MZVL22T0HBLB-00B00 (NVMe SSD)
• OS: WSL2 (Ubuntu 24.04) on Windows 11
• Compiler: GCC 13.3.0 with -O3 optimization
• Date: October 5, 2025

Key Results Summary

Testing Environment: AMD Ryzen 9 5900X, 128GB DDR4, Samsung NVMe SSD

Spacing	Time to End (10GB file)	Speedup vs Sequential
Sequential	14.13 seconds	baseline
8MB spacing	0.22 seconds	98.5% faster ⚡
4MB spacing	0.43 seconds	97.0% faster
2MB spacing	0.87 seconds	93.9% faster
16KB spacing	9.86 seconds	30.2% faster
32KB spacing	55.32 seconds	291% slower ❌

Performance Categories Discovered

Category	Spacing Range	Performance vs Sequential	Recommendation
Small Winners	4KB - 16KB	24% - 30% FASTER	✅ Use for dense sampling
Performance Valley	32KB - 64KB	94% - 291% SLOWER	❌ Avoid completely
Recovery Zone	128KB	2.5% FASTER	⚡ Breaking even point
Optimal Range	256KB - 8MB	51% - 98.5% FASTER	🚀 Best for file scanning

Quick Start

1. Build the Project

git clone <repository>
cd file_read_benchmark
./build.sh

2. Run Quick Demo (100MB test)

./demo.sh

3. Run Full Benchmark (10GB test)

sudo ./run_full_benchmark.sh

4. Run Time-to-End Analysis

sudo ./build/time_to_end_benchmark

Project Structure

file_read_benchmark/
├── src/
│   ├── main.cpp                 # Full 10GB benchmark
│   ├── test_main.cpp           # Quick 100MB test
│   ├── time_to_end_main.cpp    # Time-to-end focused
│   ├── benchmark.cpp           # Core implementation
│   ├── file_generator.cpp      # File generation
│   └── cache_control.cpp       # Cache management
├── include/
│   └── benchmark.h             # API definitions
├── build.sh                    # Build script
├── demo.sh                     # Quick demo
├── run_full_benchmark.sh       # Full benchmark runner
├── CMakeLists.txt             # Build configuration
├── BENCHMARK_REPORT.md        # Detailed analysis
└── README.md                  # This file

Executables

After building, you'll find these executables in build/:

• file_benchmark - Full benchmark with 10GB file
• test_benchmark - Quick 100MB test version
• time_to_end_benchmark - Focuses on time-to-end metrics

Key Findings

The "Valley Effect" Discovery

The benchmark reveals a surprising performance valley where mid-range spacings (32-64KB) perform dramatically worse than both smaller and larger spacings:

1. Small Spacings (4-16KB): 24-30% faster than sequential

   • Cache-friendly with sequential locality benefits
   • Good for dense sampling applications

2. Performance Valley (32-64KB): 94-291% slower than sequential

   • Cache-unfriendly seek patterns
   • Worst of both worlds: all seeks, no benefits

3. Optimal Range (256KB-8MB): 51-98.5% faster than sequential

   • Minimal seeks with fast file area coverage
   • Perfect for file scanning and validation

Coverage Speed vs Data Throughput

• Coverage Speed: How fast we scan through file area (GB/s)
• Data Throughput: Actual bytes read per second (MB/s)

For file scanning operations, coverage speed is the critical metric.

Practical Applications

✅ When to Use Sparse Reading

• File validation and integrity checks (use 2-8MB spacing)
• Metadata discovery and structure analysis (use 256KB-1MB spacing)
• Progress monitoring for large files (use 512KB-1MB spacing)
• Database/log file sampling (use 8-16KB spacing)
• Quick file format detection (use 4-8MB spacing)

❌ Spacings to Avoid

• 32-64KB range: Creates performance nightmare
• Any spacing generating >100K seeks per file

Technical Features

• Cache Control: Clears OS page cache between runs (requires root)
• Statistical Analysis: Multiple runs with standard deviation
• Data Integrity: Checksum verification prevents compiler optimization
• Comprehensive Output: Console tables and CSV export
• Configurable: Easy to modify file sizes and spacing ranges

Usage Examples

Basic Usage

# Quick test (no root required)
cd build
./test_benchmark

# Full test with cache clearing (root required)
sudo ./file_benchmark

# Time-to-end analysis
sudo ./time_to_end_benchmark

Root Privileges for Accuracy

For most accurate results, run with sudo to enable:

• OS page cache clearing between runs
• Filesystem sync operations
• Direct I/O hints

Cache-Busting Techniques

1. File Renaming: Between runs to avoid metadata caching
2. Page Cache Clearing: echo 3 > /proc/sys/vm/drop_caches
3. Direct I/O Hints: posix_fadvise(POSIX_FADV_DONTNEED)
4. Filesystem Sync: Ensures data written to disk

System Requirements

• OS: Linux (tested on Ubuntu 24.04/WSL2)
• Compiler: GCC with C++20 support
• RAM: Minimum 4GB (16GB+ recommended for large tests)
• Storage: 15GB+ free space for full 10GB benchmark
• Privileges: Root access recommended for cache clearing

Conclusion

The benchmark conclusively validates that sparse reading can be dramatically faster for reaching the end of large files, with the optimal 8MB spacing achieving 98.5% faster performance than sequential reading. However, spacing selection is critical - wrong choices can be significantly slower than sequential access.

This research provides actionable insights for optimizing large file operations in production systems, particularly for file validation, metadata discovery, and progress monitoring applications.

---

For complete analysis and detailed results, see BENCHMARK_REPORT.md