Goal
Add reproducible benchmarks to README showing zsync's performance advantage. HN loves hard numbers.
Benchmark Scenarios
1. Initial sync (cold)
- Sync a real codebase (~500 files, 50MB) to fresh remote
- Compare: rsync, mutagen, zsync
2. Incremental sync (hot) ⭐ This is where zsync shines
- Change 1 line in a large file
- Change 10 files across codebase
- Add a new file
- Compare transfer size and time
3. Cross-project dedup
- Sync project A, then sync similar project B
- Show that shared chunks aren't re-transferred
Test Setup
- Local: macOS or Linux
- Remote: Linux VM or actual cloud instance (RunPod/Lambda Labs for authenticity)
- Network: Simulate typical cloud latency (~50ms) if local
Metrics to Capture
- Wall clock time
- Bytes transferred (use
nethogs or SSH stats)
- CPU usage (optional)
Output Format
| Scenario | rsync | mutagen | zsync |
|----------|-------|---------|-------|
| Initial sync (50MB repo) | 12s | 8s | 6s |
| 1-line change in 10MB file | 10s | 5s | 0.3s |
| 10 scattered file changes | 15s | 8s | 1.2s |
Tools
hyperfine for timing
rsync --stats for transfer info
- Custom script to measure zsync transfers
Notes
- Be honest — if rsync wins a scenario, show it
- Use realistic codebases (maybe linux kernel subset, or a real ML project)
- Consider latency sensitivity (zsync's chunking overhead vs rsync's simplicity)
Goal
Add reproducible benchmarks to README showing zsync's performance advantage. HN loves hard numbers.
Benchmark Scenarios
1. Initial sync (cold)
2. Incremental sync (hot) ⭐ This is where zsync shines
3. Cross-project dedup
Test Setup
Metrics to Capture
nethogsor SSH stats)Output Format
Tools
hyperfinefor timingrsync --statsfor transfer infoNotes