# cwdio performance benchmarks

> Measured listing, copy and traversal numbers from the same library code the app ships, with the environment, the method, and what is not measured.

- Canonical: https://cwdio.com/benchmarks/
- Updated: 2026-08-15
- Product: Cwdio File Manager (cwdio) — https://cwdio.com

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](/blog/) 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](https://github.com/cwdio/cwdio/issues) with what you measured; it will be
answered with a measurement, not an argument.

## Related

- [Transfers and the queue](/features/transfers-and-queue/) — verification, resume, the journal.
- [Engineering notes](/blog/) — the decisions behind the data path.
- [Security and privacy](/security/) — the process model from a trust angle.

## Frequently asked questions

**Is cwdio slow because it is Electron?** The parts that touch files are not Electron. Listing, copying, searching and archive reads run in a separate services process that talks to the window only through small control and progress messages; file bytes never pass through the renderer or the IPC bridge. The interface is Electron; the data path is plain Node streams disk-to-disk. The numbers here are what that path measures at.

**Can I run the benchmarks myself?** Not today: the harness lives in the private source repository (npm run bench). What is published is the method, the environment and the raw numbers, regenerated with each release. If you can show a scenario where the numbers do not hold, an issue with your measurement is welcome and will be answered with one.

**What do the numbers not cover?** Interface paint, cold start, scrolling a huge list, and anything network-bound. They measure the library layer — the code that lists, copies and walks — on one specific machine. Treat them as an order of magnitude, not a promise for your hardware.