Performance on KDE Blogs

Dolphin 26.08 and KIO, part two: what got faster and smaller

Méven Car — Thu, 27 Aug 2026 00:00:01 +0000

This is the second half of what changed in Dolphin 26.08. The first half is what you can see: the features, the behaviour changes, the bugs. This one is what you can measure.

Dolphin does very little file work itself. It asks KIO, so the numbers below are mostly KIO numbers: 6.25 is the version that shipped alongside Dolphin 26.04, 6.29 is the one that ships alongside 26.08, four framework releases and 294 commits apart. The last section is 6.30, the release still to come, since several of its changes are large enough to be worth showing early.

Every figure here was measured on the same machine, with the two versions built the same way and run one after another, round by round. Where a number is not solid I say so rather than rounding it up.

Memory and object lifetimes

The 26.04 post ended by saying the next thing was to point LeakSanitizer at Dolphin. It turned into a lot of fixes, and into a CI job: KIO now runs its tests under LeakSanitizer on every merge request, which is what stops the list below from growing back.

Sebastian Englbrecht was the busiest contributor to Dolphin this cycle by commit count, and most of that work was lifetime and ownership: killing in-flight KIO jobs in destructors, deleting the Konsole part, destroying owned objects before the KIO cache tears down and fixing unowned allocations. He also added a smoke test, eight places-panel unit tests, and a rule forbidding bare QTest::qWait() with the existing waits replaced by signal-based ones, which is the sort of thing that makes the rest of the CI trustworthy. Wendi Gan fixed an occasional use-after-free crash in KConfig::sync() during exit, closing two reports, 516481 and 518433.

My own share was in both projects. In Dolphin: aborting the folder stat job when the Information Panel is destroyed, a use-after-free of the current version-control plugin, a leaked submenu in the folder-icon action and a leak in the trash settings page on exit. In KIO, besides turning the sanitiser on in CI and teaching the tests to wait for what they allocate to be deleted, three fixes are ones a user could have met: the "Move Into New Folder" drop action had done nothing at all since 6.25, because the menu was parented to a plugin destroyed the moment the action fires while the folder creation it starts runs asynchronously; FilePreviewJob armed a repeating timeout timer it never stopped, so with a context menu held open the orphaned timer could fire on a finished job and re-enter emitResult(); and KDirModel dereferenced the node of a directory that had already left the model when an earlier listing completed late.

Performance improvements in KIO between 6.25 and 6.29

The big one is the in-process worker transport. For local files KIO has for some time run the file worker in a thread of the application rather than a separate process. Even in that thread it still talked to the application over a socket, serialising every command and every block of file content through a QLocalSocket pair. In 6.29 that channel is a new ThreadConnectionBackend, an in-memory queue, and kio_file hands over owned byte arrays instead of copying them, which makes in-process reads zero-copy. This is the first half of the improvements described in the copy post from July.

Second, CopyJob no longer re-probes the destination filesystem type for every file. It called KFileSystemType::fileSystemType() per file for the FAT and NTFS checks, and on libmount builds each of those calls parses the entire mount table. Copying N files parsed /proc/self/mountinfo N times. It is determined once now. Each parse is about 57 microseconds on a host with 39 mounts, and it scales with the number of mounts.

Third, and this is the memory one, the directory lister cache got much smaller. A directory that no lister was showing any more went into a cache of ten and stayed there until nine others had displaced it. For a picture folder of 50000 files that is a lot of KFileItem and UDSEntry retained for nothing. The cache now holds three directories, which is what going back a level or two actually needs, and drops anything no lister has asked for in three minutes.

Fourth, UDSEntry got smaller, which saves memory. An entry now keeps its numbers and its strings in two separate vectors, which buys a byte for every field an entry holds. And loading now sizes each vector from what the entry actually holds: both vectors used to be sized from the count of fields alone, a third of it for the strings and two thirds for the numbers. A stat of a local file gives one string, the name, and eight numbers, so the numbers grew past their room while the strings kept more than they needed. That sizing change on its own takes a listing of 200000 local files from 528 bytes an entry to 400, which is 105.6 MB down to 80 MB, 25.6 MB saved. Loading also stopped hunting for a shared value on the fields where values cannot repeat: no two entries of a listing carry the same name, url or local path, so comparing them with the entry before never found anything to share. Reading one entry of a local folder off the wire went from 530 to 488 nanoseconds.

Smaller ones worth naming: KFileItem no longer reads .directory on slow filesystems when working out an icon name (6.28, closing bug 519189), Sebastian Englbrecht fixed QPluginLoader, QLibraryPrivate and thread lifecycle leaks in the worker machinery (6.28).

Nineteen reports were closed by fixes in KIO across those four releases. Most of them are filed against the applications rather than against KIO, since that is where a user meets the problem: Dolphin, Plasma, Konsole, KWin.

Benchmarks

Methodology

I built KIO 6.25.0 and 6.29.0 from their tags, Release on gcc 16.2.1 and Qt 6.11.1, and ran the same harness against each. The arms are interleaved one round at a time, so a CPU frequency or load excursion hits both equally, and the best of N rounds is reported.

Everything ran on one 13th Gen Core i7-1365U with 30 GB of RAM, kernel 7.1.4, on ext4, with the benchmark processes pinned to the same two cores.

Copying

KIO::copy() of N files into an empty directory, timed from job start to the result signal. Source files are created untimed, the destination is cleared untimed. cp -r is there as a raw-tool floor, not as a target.

Copying many small files is more than twice as fast as it was in April. The gain falls off as files get larger, which is what you would expect: the fix is to the per-file overhead, and once each file carries a megabyte of actual I/O the overhead stops being what you are waiting for.

There is still a gap with cp, discussed at length in the July post. KIO is doing more than cp does, but not five times more, and the batching work that closes most of the rest of that gap is still in progress.

Deleting

KIO::del() over a freshly created tree, best of three rounds. rm -rf is the raw-tool floor here, as cp -r is above, and it is handed the same list of paths the job is given rather than the folder that holds them.

Deletion improves less than copying, as expected: a delete carries no file content, so the zero-copy half of the transport work does nothing for it. What is left is the cheaper per-command round trip, 1.23x on the smaller tree and 1.25x on the larger one.

rm -rf is six times quicker than 6.29 on both trees, a wider gap than copying shows against cp. That fits: a copy at least spends real time moving bytes, where a delete is almost nothing but the per-file round trip, so what KIO adds is most of what there is to measure.

How the job is asked matters as much as the count. These runs hand KIO::del() the 5000 files one by one, the way a select-all in a file manager does. Handing it the one folder instead takes about a fifth of that on the same filesystem, because the worker then walks the tree itself instead of taking a command per file. rm given the folder rather than the 5000 paths goes from 69.4 ms to 66.8, which is the difference the filesystem charges for the two shapes. The rest of it is KIO's. That second path is the one the 6.30 section below measures.

Listing

One KCoreDirLister over an existing directory. The cold number is the first listing in a fresh process. The warm number is a later listing of the same directory, which KCoreDirListerCache answers without going to disk. The second chart is the resident growth while the lister is still showing the folder, which is what a file manager displaying that folder actually costs.

Listing is about 9 percent quicker on the 5000-file folder and 15 percent on the 50000-file one, and holds about 14 percent less memory in both cases. The memory part is the UDSEntry work described above. The warm listing is unchanged either way, 2.6 ms against 2.8 ms on the 5000-file folder and 37 ms on the 50000-file one, which is the cache answering rather than the disk.

Memory kept for folders you have left

Of everything measured here, this is what a long-running Dolphin notices most. Walk twelve directories one after another, the way you do going down and back up a tree, and then look at how much memory the process is still holding. Nothing is on screen in either case, so all of it is held for folders nobody is looking at any more.

In 6.25 a directory nothing was showing any more sat in a cache of ten and stayed until nine others displaced it. Browse through a few large folders and you are holding all of them. The cache now keeps three, and drops anything no lister has wanted for three minutes. Repeat listings do not suffer for it, which is what the warm listing above shows: re-opening a folder you just left still finds it. What the eleventh slot bought was going eleven folders back, and every user of a large folder paid for it.

6.30 improvements

None of this has shipped, so treat it as a preview rather than a result. 6.30 has several commits that touch exactly what this post measures, so I built it as a third arm and ran the same harness.

Most of what 6.30 gains comes from one change: handing over what a message carries as it is when the worker runs in the application's own process. kio_file runs in a thread of the application, but used to write its data down with QDataStream the way a process-based worker has to. Except it does not need to. Avoiding that serialisation is where the fewer allocations come from, and the entries cost less memory besides, since one no longer reserves room for fields most files never carry. Nothing changes for a worker in another process, which still has a socket between it and the application.

The other major improvement was a dormant issue. It had been there for years, and benchmarking made it visible: 50000 files listed in 1233 ms while 5000 listed in 36, 10 times the files taking 34 times as long, where listing should be close to linear.

A profile of the large case revealed 42 percent of the whole listing is KFileItem copy construction and destruction, all of it under KCoreDirListerCache::DirItem::insertSortedItems calling QList::reserve once per batch of entries. Except reserve has no relocatable fast path: on the growth path it allocates exactly the size asked for and copy-appends every element already there, even for a type declared Q_RELOCATABLE_TYPE as KFileItem. Since the previous call had sized the buffer exactly, every batch reallocated and copied the whole list. Heaptrack counted 239 such calls for 50000 files, so about six million copy constructions for fifty thousand items.

Deleting the reserve call and letting the list grow geometrically takes that listing from 1233 ms to 531 ms, over 2x quicker. What cost the time was inside those reallocations, copy-constructing every KFileItem already in the list, and a KFileItem copy is a refcount bump that allocates nothing at all. So none of it showed up in an allocation count, which is why it took a cycles profile to find.

Deleting a folder gained from af3d9e0e7, which removes a tree with the system's own calls instead of walking it, and how much depends on the shape of the tree. openat and unlinkat work from a descriptor for the directory an entry was read from, so they stop resolving a whole path for every entry, and the deeper the tree the more that is worth. Fifteen thousand files on tmpfs, deleted as one folder, with rm -rf over the same tree as the floor:

6.29 costs more the deeper the tree, four times as much at 800 levels as at ten. 6.30 does not care how deep it is, and stays within a third of rm -rf at every depth, which is about as close as a job that reports progress and can be cancelled is going to get to a tool that does neither.

Closing

The copy path still has more in it than 6.29 ships: the batching that closes most of the remaining gap to cp is written and measured in Making KIO copy many files fast and is not finished yet. The listing path has an open question of its own, which is that an entry could carry its fields more cheaply again; a branch that does it trades about two percent of listing time for eleven percent of the memory an entry holds, and which of the two is the better trade depends on how many entries you are holding.

Enjoy the speed.

Dolphin 26.08, and KIO perf improvements

Méven Car — Wed, 26 Aug 2026 00:00:01 +0000

Dolphin 26.08 has been released. Here is more of what changed in it, and in the KIO framework underneath it.

The version of KIO that shipped alongside Dolphin 26.04 was 6.25. The one that ships alongside 26.08 is 6.29, four framework releases and 294 commits later. A fair part of this post is about that, because the largest performance change of this cycle is not in Dolphin at all. If you only read one thing, read Making KIO copy many files fast, which is the story behind why copying a folder of small files in 26.08 takes less than half the time it did in 26.04.

New features

Grouping is no longer tied to sorting. Ramil Nurmanov added an explicit group role, so grouping by type no longer forces you to sort by type as well. The old "Show in Groups" toggle is replaced by a "Group By" menu, which lets you turn grouping off, keep the old "Same as Sort" behaviour, or pick a criterion outright. Inside each group the normal sort role is still used as a secondary key. (989c0f4f0)

The filter bar tells you what it is doing. Alessio Bonfiglio replaced the hidden auto-detecting regex behaviour with an explicit mode selector offering Plain Text, Glob and Regular Expression, plus a case-sensitivity toggle. The old behaviour tried to guess: typing a name containing *, ? or [ silently switched the bar to a regular expression, which made a file genuinely named [draft].txt impossible to filter for. An invalid expression now turns the bar red instead of quietly doing something else. (3084a4e11)

A "Folder Name" column in the details view, by Jussi Räsänen, closing a request from 2021. It is most useful when a search or an expanded tree puts files from several folders on screen at once. (4a7be9f25)

Per-folder zoom, by Wagner Soares. When you are not using global view properties, the zoom level is now remembered per folder like the other view properties are. (0f7a9c681)

"Focus Other View", by Felix Ernst. The "Switch between views with Tab key" setting is gone, replaced by a real action you can bind to whatever you like. It moves focus to the inactive split view, and opens a split if there is not one yet. (12b4a8a91)

Close tabs to the left or right, by Ramil Nurmanov. (91e7c0c1e)

A button to restore view properties to their defaults, which I added for the per-folder view properties case. It enables and disables itself depending on whether the current folder already matches the defaults. (70f34211c)

Type-ahead feedback in the status bar, by Felix Ernst. As you type, the status bar shows the keys you have typed and which file name they selected, so a type-ahead that lands somewhere unexpected is no longer silent. (1e13c6abb)

The terminal panel can be resynchronised with F5, by Antti Savolainen, closing bug 510557. When a foreground program is running in the panel, the terminal and the view can drift apart. Konsole does not signal when that program exits, so responding to F5 is the practical answer. (07baa7bb6)

KDE Connect integration, by Kai Uwe Broulik: an "Open KDE Connect" button when browsing the kdeconnect scheme (d5903bd81), and a proper placeholder for a KDE Connect folder (dfef28748).

Session restore for the first instance, by Sergey Katunin, closing bug 464693. If Dolphin is not already running and something launches it with --new-window, as browsers and Kate do, the session is restored rather than discarded. (173794ce1)

Behaviour changes

These are the changes most likely to surprise you, so they are worth naming explicitly.

Create New Folder is now two actions. Ctrl+Shift+N and the context menu entry shared one action, so the menu advertised a shortcut that did something subtly different: the shortcut creates in the viewed directory, the menu entry in the folder you clicked. They are separate actions now, and the context menu one has no default shortcut. (705e366aa)
"Empty Trash" moved in the context menu, by Antti Savolainen, closing bug 518713. It now sits with the other destructive actions rather than next to harmless ones. The reporter had been emptying the trash while reaching for something else. (7d81e3092)
"Open Terminal Here" only appears for folders, not for files, by Brijesh krishna. (8a9f7d9d4)
The play arrow over video previews in the Information Panel is gone, by Ryan Nosurname. There is already a play button and a seek bar directly beneath it. (71f8db089)
Icon overlays are drawn at a fixed size rather than composited into the thumbnail and rescaled with it (bug 498211). Emblem size was previously inconsistent from file to file, because each thumbnail was rescaled by its own factor, and slightly cropped at fractional display scaling. (63f21036e)
Special folders keep their saved view properties even with global view properties enabled, by Pan Zhang (bug 520089, 2e665e1b5).
Names like file.2.txt sort naturally, by Pan Zhang (bug 411707, 0d10eff37).

Who wrote it

Counting commits that are new in 26.08 and not already in a 26.04.x release, and leaving the translation robot out of it:


commits	207, of which 97 code changes
lines	3822 added, 772 removed, net +3050
contributors	22
first time in Dolphin	13 of those 22
returning	9

The busiest by a wide margin:

Contributor	commits	added	removed
Sebastian Englbrecht	31	1145	87
Méven Car	29	706	236
Pan Zhang	6	424	58
Felix Ernst	5	250	165
Ramil Nurmanov	2	428	54
Alessio Bonfiglio	2	406	22
Kai Uwe Broulik	2	58	4
Akseli Lahtinen	2	49	42
Antti Savolainen	2	37	12
Filip Fila	2	13	5
Oleksandr Bondar	2	11	6
Sergey Katunin	2	11	5

Commit counts and line counts do not rank people the same way. Ramil Nurmanov and Alessio Bonfiglio wrote two commits each and still added more lines than anyone except the top two, because grouping by a separate criterion and the filter bar modes each arrived whole. Ryan Nosurname's single commit is the opposite shape: removing the video preview play arrow takes away 43 lines and adds none.

Thirteen people landed their first Dolphin commit this cycle: Antti Savolainen, Areeb Faisal, Brijesh krishna, Evgeniy Harchenko, Filip Fila, Florian RICHER, Jussi Räsänen, Ketal Wang, Oleksandr Bondar, Ramil Nurmanov, Ryan Nosurname, Sebastian Englbrecht and Wagner Soares. Kudos to them! Several are long-standing KDE contributors who had simply not touched this repository before, so read it as new to Dolphin rather than new to KDE.

The other 110 commits were mainly translation commits. Thank you, translators!

Bugs fixed

Nineteen bugs are fixed in 26.08 that were not already fixed in a 26.04.x point release. Ten of them are the changes described above, so here are the other nine:

Bug	What	Who	Commit
492298	Menubar visibility applied after the UI has loaded	Oleksandr Bondar	`c3ef613f`
506884	Inline rename preserved when the item scrolls out of view	Pan Zhang	`5e35194b`
508465	Item widgets use style primitives instead of custom painting	Akseli Lahtinen	`61b6e173`
509150	Wrong item count in the Size column for folders of 200+ entries	Pan Zhang	`914cd901`
510469	Animated-height widgets no longer scroll the viewport	Pan Zhang	`cde91dd7`
514401	Re-triggering an inline rename made robust	Méven Car	`7ca6daea`
515236	No spurious history entry when leaving search results	Pan Zhang	`35b309aa`
518285	Non-Breeze styles may style the non-toolbar navigation bar	Filip Fila	`76f6eb07`
523348	Delete action shown in selection mode in the trash	Méven Car	`d392e6b5`

Two regressions worth knowing about

Icons could be missing entirely. On a freshly opened view every item drew a blank where its icon should be, and it stayed that way until the view mode was switched or the zoom slider moved (bug 523228). A regression from per-folder zoom, fixed in 9c652faca. That fix brought one of its own, turning previews off in icons view rendering at 16 pixels rather than the 32 that mode is set to (bug 524606), fixed in 57c6b10e1. Both are on the release/26.08 branch and ship in Dolphin 26.08.1, due in the first half of September 2026.

Service submenus disappeared from the context menu. Entries that a service menu file groups into a submenu were missing from the context menu, in any application that builds one with KFileItemActions, Dolphin included (bug 524239). A regression from 148b9253d in 6.29, fixed by Luis Bocanegra in 774defb94, which ships in KDE Frameworks 6.30, due in the first week of September 2026.

Neither was found by a test, and both have one now: dolphinitemlistviewtest, which is new, and three cases in dolphinviewtest for the per-folder cache, and testServiceMenuSubmenuActions with a submenu.desktop fixture in KIO.

Closing

If you want to help, the leak and lifetime work above is a good way in, and so is picking a bug from the list. The KIO copy path still has more in it than 6.29 ships: the batching that closes most of the remaining gap to cp is written and measured in Making KIO copy many files fast but not yet finished.

That's all, folks.

Making KIO copy many files fast

Méven Car — Tue, 28 Jul 2026 00:00:01 +0000

There is a bug in KDE's bug tracker that is almost as old as some of our contributors: bug 342056, "Ridiculously slow file copy (multiple small files)", reported by Alexander Nestorov back in 2014. The report is blunt: copying a 15 GB folder of roughly 3 million small files took 5 to 10 hours in KDE, versus about 20 minutes with rsync. One commenter summed up the mood:

I generally use cp and rsync instead of dolphin for anything more than a few files.

That bug has been stuck in my head for a while, so this post is about finally fixing it. I have been working on KIO's copy path, and I want to walk through where the time was going, some history that explains why, and show numbers across KIO versions including a plain cp for reference.

At with any optimization, let's measure first:

Where a KIO 6.28 copy of 5000 small files spends its blocking time, and there is no single hotspot. Each file blocks in a burst of short syscalls: reading the mount table (/proc/self/mountinfo), opening the source and destination, and round-tripping a command to the worker over an internal socket. The socket round-trips, the send and receive plus the waits for each reply, are the frames highlighted in red, about 15% of the blocking here, spread as thin slivers across both threads because every one of the thousands of files pays them. The frames in green are the real filesystem work the copy cannot avoid: the statx and openat calls, copy_file_range moving the bytes, and the ext4 metadata updates beneath them. That per-file storm, not any single call, is what the rest of this post discusses. (Off-CPU flame graph from sched:sched_switch, weighted by number of blocking switches; click to open the full SVG.)

A little history

KIO is the layer behind almost every file operation in KDE software, from Dolphin's copy and paste to the network transparency that lets you open sftp:// or smb:// URLs as if they were local. Its design goes back to the KDE 2 days, around the year 2000. Back then the answer to "how do I do I/O without freezing the UI" was not a thread but a separate process: a worker (we used to call them kioslaves) is launched for a protocol and talks to the application over a socket. This predates usable threading on Linux (Native POSIX Thread Library only landed in Linux 2.6 in 2003), so processes plus socket IPC was the portable, robust choice, and it still is for network protocols today: if an smb:// worker crashes, your file manager does not go down with it.

The flip side is cost. Every request and its reply are serialized and sent over that socket, with an event-loop hop on each side. For file:// that overhead buys you nothing, because there is no untrusted network on the other end, just the local disk.

In 2022 David Faure changed that: Implement running KIO workers in-process using a thread landed in Frameworks 5.95. Since then the file worker runs on a thread inside the application instead of as a separate process (other protocols stay out-of-process for robustness). That removed process launch and context-switch cost.

No socket between the thread and the app (6.29)

There was still a catch that had been hiding in plain sight: even in-process, the worker thread and the application talked to each other over a socketpair, serializing every command as if they were separate processes. Once the thread was used, that socket was pure overhead.

That's the red highlight in the first flamegraph.

So in-process workers now use a real in-memory transport instead of a loopback socket. A new ThreadConnectionBackend handles commands, and for reads the actual data buffer, straight to the peer thread, with no serialization and no syscall, which makes in-process file reads zero-copy. This is the biggest single jump in the numbers below, and it has landed on master for 6.29 (kio!2279).

Next: batching the copy and the stat (under review)

The changes above make each command cheap. The remaining cost is that there are still so many of them: copying N files is N separate file_copy jobs, each one going through the job scheduler and taking its own round-trip to the worker. For many small files that fixed per-file cost, not the data, is what dominates.

CopyJob can dispatch a whole batch of plain local-to-local files to the worker in one command, and the worker copies them (using copy_file_range, and reflink on filesystems like Btrfs or XFS that support it). Each file still gets its progress signal, its byte accounting, its undo entry, and anything the worker cannot do blindly — an existing destination, an unreadable source, a rename or skip decision — is handed back to the normal per-file path. The gate is conservative on purpose so a hung mount can never freeze the batch (kio!2282).

The same copy on 6.29 with batch-copy: the red socket round-trips are gone. Two things removed them: the in-memory transport from the previous section (no socketpair at all) and batch-copy folding a whole run of files into one command instead of one round-trip each. What is left is real filesystem work: the green frames are the copy itself, copy_file_range moving the bytes, the openat and statx calls, and the ext4 metadata beneath them. The wide plateau that is not green is the benchmark loop deleting each pass's files before the next run (unlink), which is teardown rather than part of the copy.

Before copying, CopyJob stats every source, which is another per-file round-trip. The follow-up batches the stat phase over the same in-process lane. This is the batch-copy-stat column below.

Both of these are under review and targeted at a release after 6.29, so treat their columns in the table as a preview of what is coming rather than something you can install today.

Numbers

Methodology: a 13th-gen Intel Core i7-1365U laptop, everything built RelWithDebInfo without any sanitizer, copying onto a real ext4 volume (so no reflink shortcut, copy_file_range moves real bytes). Each KIO version supplies both its own libKIOCore and its own kio_file worker. Times are the median of 5 runs (3 for the large set) after a discarded warm-up, so caches are warm and equal for every version. cp -r --preserve=mode,timestamps is included as the floor, since that is what the bug reporter reached for instead of Dolphin.

5000 files of 4 KB each (the many-small-files case from the bug):

Version	Median time
`cp -r` (coreutils)	81 ms
KIO 6.28.0	1616 ms
KIO 6.29-dev (master)	396 ms
KIO 6.29-dev + batch-copy	88 ms
KIO 6.29-dev + batch-copy-stat	93 ms

1000 files of 5 MB each (bulk data, where the copy is I/O-bound):

Version	Median time
`cp -r` (coreutils)	1312 ms
KIO 6.28.0	1997 ms
KIO 6.29-dev (master)	1687 ms
KIO 6.29-dev + batch-copy	1506 ms
KIO 6.29-dev + batch-copy-stat	1454 ms

The small-files case is the story. KIO 6.28 was about 20x slower than cp, which is exactly the ratio the 2014 report complained about. Removing the socket for in-process workers, together with no longer probing the destination filesystem once per file, takes it from about 1.6 s to 0.4 s (roughly 4x). Batching the copy takes it to 88 ms, essentially cp speed and about 18x faster than 6.28. That "I use cp instead of dolphin" line finally has an answer.

The large-file case was already well covered before any of this work, and the table shows it: the copy is bound by moving the bytes, so even KIO 6.28 stayed close to cp there, and the per-file optimizations barely move the number (batch-copy lands within about 15% of cp). That is the whole reason this effort targets many small files instead, where the fixed per-file cost, not the data, is what dominates.

batch-copy and batch-copy-stat come out tied here: the benchmark copies a single directory, so its entries arrive in one listing and batch-stat has nothing to batch. It helps the other case, copying a large selection of individual files that would otherwise be one stat round-trip each. Since it removes the round-trip and not the stat call, the win is largest when stats are cheap, not when the disk is slow. Read the two as equal on this test.

And cp will almost certainly stay a little ahead, by design: KIO does more than copy the bytes. It reports per-file progress, can be paused and cancelled, keeps an undo record, preserves permissions and timestamps, resolves conflicts, and tells any open file manager what changed so its view refreshes. That work is not free, and the goal was never to beat cp, only to make the local case fast enough that reaching for cp instead of Dolphin stops being the obvious choice.

Caveats and what is next

These are laptop numbers on one ext4 disk with warm caches, meant to compare versions, not to be absolute. On Btrfs or XFS the batch path reflinks instead of copying, which changes the large-file picture entirely. The batch fast path only engages for plain local-to-local copies on a responsive filesystem; anything else (network, FAT/NTFS, conflicts needing a dialog) falls back to the existing per-file path, unchanged.

Thanks to David Faure for the in-process worker threads that made all of this possible, to Frank Reininghaus for the earlier listing fixes, and to Alexander Nestorov for a bug report that aged well enough to still be worth closing.

That's all, folks.