- Home
- Benchmark
IDM vs Zephyrus, timed to the millisecond.
Both apps on the same PC, downloading from the same test server, in alternating runs. The server's own log says when each request arrived and when the last byte left, so nothing relies on either app's word.
The race
LOD Zephyrus Download Manager1.0×faster
Played in real time from the medians.
Faster in every scenario.
How many times faster Zephyrus finished, from command to finished file. The whisker is the 95% interval of the ratio; the scale is logarithmic.
480 connections against 2.
A server that allows two connections at a time. Every square is one connection it saw in a typical run.
Zephyrus0Learns the limit from the server's answer, keeps to it, and remembers it for next time. Finished in 12.6 s.
Retried about 250 times a second against the refusals. Finished in 15.9 s.
Every run is a dot.
Seven downloads, each run at least seven times by both apps. The bar is the middle half of the runs, the line the median.
IDM takes about three seconds to accept a download from its command line before it sends anything; downloads caught by its browser extension skip that step. That is why "Transfer" is the fair engine-to-engine view. "End to end" is here too.
Where the time goes
Median startup (command to first request), transfer and finish of each app, per scenario.
What it costs the computer
Median CPU time each app used during a run, and its peak memory. Zephyrus draws its window with the GPU, which takes more memory than IDM's classic Windows controls.
All the numbers
| Scenario | App | n | End to end, median (IQR) | 95% CI of median | Transfer | Startup | Connections | Requests | CPU | Peak memory | p |
|---|
The report
End-to-end medians with interquartile ranges, the ratio with its 95% interval, and the Mann–Whitney test, as tools/bench/report.py writes them.
How it was measured
- Server. The lab server from this repository, on 127.0.0.1, serving generated content. It throttles, delays, refuses or cuts connections per scenario, and logs every request with millisecond start and end times.
- Clients. IDM and Zephyrus, both at default settings (8 connections), each given the download through the same documented command line:
/d URL /p folder /f name /n. Both save to the drive that holds IDM's temporary folder, so neither pays a cross-drive copy. - Timing. End to end: from issuing the command to the finished file under its final name, polled every millisecond on a monotonic clock. Zephyrus renames its finished file into place; IDM creates the final file early and fills it, so for IDM the moment it reaches full size counts. Transfer: the server's first request to its last byte, read on the same clock through a calibration request before each run.
- Fairness. The apps alternate, IDM first on even runs and Zephyrus first on odd ones, so drift on the machine hits both. One warm-up run each is discarded. Failed runs are counted, not dropped. Before every run the harness waits until the loopback is quiet: against a server that refuses extra connections IDM retries about 250 times a second, leaving thousands of closed sockets for half a minute; without the wait, whichever app ran next was timed on that backlog.
- Statistics. Medians with interquartile ranges, bootstrap 95% intervals (10,000 resamples) for each median and for the ratio of medians, and a two-sided Mann–Whitney U test.
- Limits. A loopback link has no real distance or packet loss; the faults stand in for them. Results are from one machine. Run it yourself:
python tools/bench/bench.py, thenpython tools/bench/report.py.
See it for yourself: it's free.
Download LOD Zephyrus Download Manager