RookparcelBenchmarks
Rookparcel's daemon beside qBittorrent, Transmission, Deluge and rTorrent: the same machine, the same torrents, every client at its own defaults. The harness, the method and the raw numbers are public, so you can run it yourself.
In short
- A big library stays small. With 10,000 torrents Rookparcel used 60 MB after a restart, a tenth of qBittorrent's 612 MB, and listed all of them 0.19 s after it started. Right after adding them it used 319 MB, about as much as Transmission: Rookparcel keeps a torrent's metadata in memory only while the torrent is active, and the next start leaves out the rest.
- Fast and frugal with one peer. Downloading 2 GiB from one peer on the same machine, Rookparcel reached a median 3,592 MiB/s and used 1.04 seconds of CPU per GiB, half as much as qBittorrent and Deluge. rTorrent used less CPU per GiB (0.85 s) but slowed down near the end of every download.
- Quiet when idle. Every client stayed under 1.3% of one core with 10,000 torrents; Rookparcel and qBittorrent used the least, under 0.1%.
10,000 torrents
Every client got the same 10,000 generated torrents (10 MB to 20 GB, about 1,500 pieces each, three in five with several files), added started, with no data on disk and a tracker that refuses connections. Memory is the resident memory (RSS) of the client's processes after 60 seconds of settling.
Then each client was stopped and started again; the time is from starting the program until its API lists all 10,000 torrents.
All the numbers
Add is from the first add request until all are listed, through each client's own API (Deluge's daemon takes them in batches of 100 over its RPC). PSS divides shared libraries among the processes using them. Idle CPU is 60 seconds without any API call, as a percentage of one core. Empty is the client with no torrents.
10,000 torrents
| Client | Add (s) | Start with all listed (s) | Memory, RSS (MB) | PSS (MB) | Idle CPU (%) | Empty RSS (MB) |
|---|---|---|---|---|---|---|
| Rookparcel | 1.3 | 0.19 | 60.2 | 56.1 | 0.07 | 9.5 |
| qBittorrent | 1.2 | 0.86 | 612 | 597 | 0.07 | 53.5 |
| Transmission | 4.9 | 1.00 | 327 | 315 | 0.77 | 20.8 |
| Deluge | 517 | 5.76 | 701 | 686 | 0.28 | 68.4 |
| rTorrent | 24.7 | 22.62 | 2,142 | 2,132 | 1.25 | 16.4 |
1,000 torrents
| Client | Add (s) | Start with all listed (s) | Memory, RSS (MB) | PSS (MB) | Idle CPU (%) | Empty RSS (MB) |
|---|---|---|---|---|---|---|
| Rookparcel | 0.1 | 0.07 | 15.1 | 10.9 | 0.05 | 9.5 |
| qBittorrent | 0.1 | 0.18 | 105 | 90.1 | 0.07 | 53.6 |
| Transmission | 0.5 | 0.09 | 52.4 | 40.4 | 0.20 | 20.9 |
| Deluge | 51.6 | 0.91 | 135 | 120 | 0.22 | 68.5 |
| rTorrent | 1.1 | 0.55 | 230 | 219 | 0.10 | 16.5 |
Downloading
One 2 GiB file of random data, seeded by a reference qBittorrent on the same machine, downloaded five times by each client with a fresh profile. Speed and CPU time are taken between 10% and 80% of the file, from the kernel's own byte counts; every downloaded file was checked against the original.
Transmission held exactly 62.4 MiB/s in every run, which looks like the limit of how many requests it keeps open to a single peer rather than of its engine; with many peers it spreads out. rTorrent was fast until about 1.7 GiB and then flushed its memory-mapped pieces at about 32 MB/s, which is why its downloads took two minutes from the first byte to the last.
| Client | Version | Runs | Throughput (MiB/s) | range | CPU s per GiB | range | First byte to done (s) |
|---|---|---|---|---|---|---|---|
| Rookparcel | rookparcel-nox 1.0.1 | 5 of 5 | 3,592 | 2,124–3,605 | 1.04 | 0.94–1.16 | 1.6 |
| qBittorrent | v5.1.4 | 5 of 5 | 1,471 | 1,380–1,662 | 2.14 | 2.06–2.22 | 2.5 |
| Transmission | Transmission 4.1.1 (56442e2929) | 5 of 5 | 62.4 | 62.4–62.5 | 2.66 | 2.66–2.72 | 41.2 |
| Deluge | Deluge 2.2.1.dev0+20250824 (libtorrent 2.0.12.0) | 5 of 5 | 1,566 | 1,217–1,670 | 2.11 | 1.97–2.22 | 2.0 |
| rTorrent | rTorrent 0.9.8 (libtorrent 0.13.8) | 5 of 5 | 1,924 | 1,721–2,056 | 0.85 | 0.81–0.94 | 126 |
How it was measured
- Machine: a VMware Workstation virtual machine with 8 vCPUs and 8 GB of RAM on an Intel Core i9-13900K, running Ubuntu 26.04.1.
- Clients: Rookparcel 1.0.1, the published Linux release checked against its
SHA256SUMS; qBittorrent 5.1.4, Transmission 4.1.1, Deluge 2.2.1 (libtorrent 2.0.12) and rTorrent 0.9.8 (libtorrent 0.13.8), Ubuntu's own packages. All ran as headless daemons. - Settings: a fresh profile each time, DHT, local peer discovery, peer exchange and port mapping off so no outside peer takes part, everything else at each client's defaults (queueing, caches, connection limits, encryption). Nothing was tuned for Rookparcel.
- CPU time is user plus system time of all the client's threads, from
/proc. Data for the downloads lived on a RAM disk, so no hard disk was measured. - Transmission is confined by Ubuntu's AppArmor profile to its service user's folders, so it ran as that user, as the packaged service does.
The harness is tools/bench (Python, standard library), the full method and how to run it again are in BENCHMARKS.md, and every run's raw results, with per-thread CPU and a trace of each download, are in docs/benchmarks. If you get different numbers, please tell us.
Limits
- A virtual machine does not see when its host is busy, and counts that time as the guest's CPU time. The downloads were repeated five times in a changing order and the medians are shown; single runs varied (Rookparcel's slowest was 2,124 MiB/s).
- Two programs on one machine have no latency, no packet loss and no swarm. The downloads show the cost of each client's code, not internet speeds.
- The seed took TCP only, so that every client used the same transport. Clients that try uTP first waited for that attempt to fail before they connected; that wait is left out of the comparison.
- The 10,000 torrents had no data and no reachable tracker, so the clients held them without transferring anything. Each client's defaults decide how many of them are active at once.
- rTorrent 0.9.8 is the version Ubuntu ships; newer rTorrent releases exist. The GUIs (Rookparcel's Windows and GTK programs, qBittorrent's desktop app) were not measured here.