What these clients actually weigh

Four SSH and SFTP clients installed on the same Mac on the same afternoon, measured with a script that is published below. Install size, process count, and physical memory with the application open and idle.

Two columns you might expect are missing, and the reason is in the method: connection time and transfer speed cannot be measured honestly from outside a graphical application. What can be measured instead is the transport itself, and it has its own row.

The numbers

Sort by any column. An empty cell means the figure was not measured, never that it is zero — the reason for each gap is spelled out further down.

Seen as bars

Installed size

Megabytes on disk after installation

Memory at idle

Physical footprint across the whole process tree

How to read this

These are not benchmarks of speed. Nothing here tells you which client connects faster or moves files quicker, because none of that was measured — see below for why.

What is measured is what an application costs you while it sits there: the space it takes on disk and the memory it holds with no connection open. On a laptop with four applications running that is the number you feel, and it is the number that differs most between a native application and one carrying a browser engine or a Java runtime with it.

One figure deserves suspicion rather than trust: Cyberduck's 510 MB. A Java heap is sized from the machine's RAM, not from what the application needs, so on a machine with different memory that number will be different. Do not carry it over to your own hardware.

Method

Machine. One MacBook on Apple silicon, macOS 26.5.2, 16 GB of RAM. Every client was measured on the same machine on the same day, with the others closed.

Install size is du -sm on the installed application bundle.

Memory is the sum of phys_footprint across every process belonging to the bundle, read with the system's own footprint tool. Not RSS: RSS counts shared pages once per process, and for an application made of fifteen processes the sum is inflated several times over.

Idle means launched, left alone for twenty-five seconds, with no connection opened. Three runs per client, application quit between runs, median reported.

Runtime is read from the bundle: an Electron framework, a bundled JVM, or neither.

What is deliberately not here

A fourth omission, for completeness: an earlier version of the script reported a readiness time. All three clients came out between 2240 and 2254 ms, which is not a property of the applications — it was the floor of the sampling loop. The metric measured the script and has been removed rather than published.

The transport, measured separately

Every client in this table speaks to the same servers over the same network. That part is common to all of them, and it can be measured — just not per client. These are OpenSSH's own numbers for one connection and one 10 MB upload, over a long-haul link.

The interesting part is not the numbers but their steadiness. Across ten runs the connection took between 2573 and 2657 ms — a spread of three per cent. The same 10 MB upload took anywhere from 8.6 to 22.8 seconds, nearly a factor of three. On a long link, setting up a connection is predictable and bulk transfer describes the link at that moment, not the software. Which is another reason no client in the table is given a throughput figure.

Reproduce it, or contribute data

Both scripts are plain shell and need no dependencies beyond what macOS ships. Neither needs sudo.

app-footprint.sh measures installed clients: size, runtime, process count and idle memory, with a CSV output. It refuses to close the application it is itself running inside, which is not a hypothetical — this table was produced from a terminal running inside one of the clients being measured, and the first version of the script would have terminated its own run.

benchmark.sh measures the transport against a host of yours: ssh host true for connection, an sftp put for transfer, N runs, minimum and median, appended to a CSV. It forces ControlMaster=no, because with multiplexing on, every run after the first reuses an open socket and reports single-digit milliseconds.

If you run either on hardware or a link that differs from this one, the numbers are worth having and this table has room for them. Send them to support@conchshell.app with the machine and the date, and they go in with your attribution.

Two rows are open by construction: MobaXterm and WinSCP have no macOS build, so they are unmeasured here. Anyone with a Windows machine can fill those in.

Where Conchshell stands, plainly

It is the smallest of the four on disk, by a wide margin, and it is the only one of the four that is not carrying a browser engine or a Java runtime. That is the whole of the claim.

Its idle memory is not in the table, and the reason is not flattering: the script was run from a terminal inside Conchshell itself, so the application was hosting a live session rather than sitting idle. With that session open it held 70 MB, which is an upper bound rather than an idle figure. A cold measurement needs the script run from a different terminal, and it will go in when it is done.

Download Conchshell free