These are the measured numbers for the three operations people feel most — listing a large folder, copying many files and walking a tree — run against the real library packages the application uses, on one machine, five runs each. They are published rather than claimed so the “Electron is slow” question has something to check against; treat them as an order of magnitude, not an absolute.
Results
Generated 2026-06-12 · Windows x64 · Intel Core i7-1165G7 @ 2.80 GHz · Node 25.7 · 3 benchmarks × 5 runs.
| Benchmark | Workload | Median | Mean | Min | Max | Throughput |
|---|---|---|---|---|---|---|
| Directory listing | 20,000 entries | 161.3 ms | 158.0 ms | 145.2 ms | 169.3 ms | ~124,000 entries/s |
| Copy throughput | 64 MiB in 256 files | 330.8 ms | 326.5 ms | 279.2 ms | 378.6 ms | 193.4 MiB/s |
| Recursive traversal | 256 entries | 3.1 ms | 3.1 ms | 3.0 ms | 3.4 ms | ~83,000 entries/s |
The listing figure means a 20,000-file folder is enumerated, stat’ed and sorted in about a sixth of a second on a 2020 laptop CPU. The copy figure is many small files (256 KiB each) — the case that punishes per-file overhead — sustained at roughly 190 MiB/s on that machine’s local storage, including the per-file bookkeeping the queue does.
What is measured, and how
- The library packages, not a mock. The harness drives
@cwdio/vfs(listing, traversal) and@cwdio/file-ops(the copy engine and its queue) — the same code the app calls through its services host. There is no separate “benchmark path”. - Five runs each, reporting median, mean, min and max, so a single warm-cache outlier cannot flatter the result. The statistics and formatting helpers are unit-tested.
- Regenerated per release with the harness in the source repository; the environment line above is emitted by the harness itself.
Why Electron is not the bottleneck
cwdio’s interface is Electron. Its data path is not: all file work — listing, copy/move/delete, search, archive reads, remote transfers — runs in a dedicated services process. Bytes move disk-to-disk or socket-to-disk inside that one process as streams with backpressure; the window receives only small control and progress messages, coalesced to a few per second. Nothing is serialised through the renderer to be written back out the other side. That is an explicit architectural decision (recorded as an ADR in the project’s engineering notes), and it is what the numbers above are measuring: Node streams and the filesystem, with the UI out of the way.
Two consequences you can feel: a 10 GB move does not stall the interface, and a crash of the window does not corrupt a copy in flight — the queue is journaled and resumes.
What is not measured
- Interface paint — how fast a list scrolls, how quickly a panel redraws. Different question, different harness.
- Cold start. Electron applications pay a fixed startup cost that a native app does not; cwdio does not pretend otherwise and does not measure it here.
- Network-bound work. SFTP throughput is your link, not cwdio’s code.
- Your machine. The numbers are machine-specific. Faster storage and CPU move them; a spinning disk or a network share moves them the other way.
Reading them honestly
The point of publishing is not that cwdio is the fastest file manager — a native tool with a tuned listing path may well beat 124,000 entries per second. The point is that the “Electron tax” people expect on the file work does not appear, because the file work is not done in Electron. If you have a scenario where it does appear, open an issue with what you measured; it will be answered with a measurement, not an argument.
Related
- Transfers and the queue — verification, resume, the journal.
- Engineering notes — the decisions behind the data path.
- Security and privacy — the process model from a trust angle.