The same 8 MB file, the same connection, the same phone: an upload that took 54 seconds now takes 4. There is nothing to turn on.
Available in Term v26.1.7 and later.
Written
Uploads from the SFTP browser are several times faster, and so are downloads of large files. The further away the server, the bigger the difference — which is exactly where moving files used to hurt. There is no setting to find: files simply move at a different speed.
Everything else is unchanged. A transfer still shows its progress and can still be cancelled mid-flight, and it still only replaces the file at the far end once it is complete — an upload that fails leaves what was already on the server exactly as it was.
An 8 MB file to a real OpenSSH server over a link with 200 ms of round-trip delay — roughly what you get to a server on another continent. Timed by the app itself, on the same phone, minutes apart.
What disappeared was waiting, so the further away the server, the more there was to save. Even a nearby server, which was never slow, moves about fifteen times faster now.
| Server | Upload, before | Upload, after |
|---|---|---|
| Nearby (20 ms) | 1.06 MB/s | 16.1 MB/s |
| Another continent (200 ms) | 0.15 MB/s | 2.10 MB/s |
Both rows are the same file with the same delay in front of the same server. The 200 ms row is the phone, from the chart above; the 20 ms row was run from a computer, because a link that quick is easy to arrange there and awkward over Wi-Fi.
Downloads of files under 4 MB are deliberately unchanged: a single stream was already close to as fast as one can go, and the trick that makes a large file quick costs more than it saves on a small one.
Faster usually means working harder. Here it is the other way round.
Sending an 8 MB file encrypts exactly as many bytes as it did before. But the processor time the app spent on that upload fell from 2.2 seconds to 0.33 — because most of the old 54 seconds were spent awake, waiting for the server to answer, rather than doing anything. A shorter transfer is a cheaper one.
The download used 0.35 seconds of processor time before and 0.36 after, for three and a half times the speed. The work did not change. The waiting did.
The old transfer sent one small piece of the file at a time, waited for the server to confirm it before starting the next, and asked the server to write each piece to its disk on the way past. On a link where every round trip costs a fifth of a second, almost all of the time went on that waiting — the connection sat idle for most of it. Now several pieces are on their way at once, and a large download is fetched as four parallel streams and reassembled as it arrives. Same protocol, same server, nothing to change at the other end.
These are single runs on one device. One phone, one 8 MB file, and the delay added in front of a server on the same machine so that the number is repeatable. Your link is not a lab: a slow uplink, a busy Wi-Fi network or a loaded server all land in the total, and nothing here makes a transfer faster than the connection it runs on.
On a very poor connection you may now see a transfer stop instead of crawl. Keeping several pieces in flight needs a link that can hold them; on one that cannot, the transfer gives up with "the server stopped responding" rather than inching along for several minutes. The file on the server is left exactly as it was, and retrying on a better connection is the fix. We would rather tell you a transfer is not going to work than let it pretend for ten minutes.