Performance
What DeskDrawer does to stay responsive on large, cloud-backed and network-connected desktops — and what can still make it slow.
The design rule#
The interface thread never waits on the file system. Everything else on this page follows from that one rule.
Idle cost#
At rest, DeskDrawer is doing nothing. There is no polling loop, no timer sweeping the desktop, no background service. It waits on:
- a change notification for the desktop folder
- a change notification for the Recycle Bin
- ordinary window messages
The periodic Recycle Bin check that existed before 1.1.0 was removed precisely because a timer that fires forever is a permanent tax on a machine that is otherwise asleep.
Startup#
Boards are drawn as soon as the layout is read; icons arrive afterwards. A board with unresolved icons shows placeholders and fills in, rather than waiting for two hundred shell calls to complete first. That was the 1.1.5 change, refined in 1.1.6 so that a large or cloud-backed desktop no longer sat on grey placeholders.
Icons#
Icon resolution is genuinely expensive — Windows may read the file, locate an associated application, extract a resource, or ask a cloud provider. DeskDrawer resolves each icon once on a background thread and keeps the result in the Icon cache. A file that is still downloading gets a generic icon immediately and its real one when the download completes.
The slow cases, and what was done about them#
Almost every performance bug in this product's history has been the same bug wearing a different hat: a file-system call against an unreachable location, made on the interface thread. Such a call does not fail quickly; it blocks until a network timeout, freezing everything — including, distinctively, the mouse wheel.
| Case | Release |
|---|---|
| Hovering a file on an offline share, or a not-yet-downloaded cloud file, to build an info tip | 1.1.4 |
| A board holding a shortcut to an offline network location | 1.2.2 |
| Large paste and drag operations | 1.2.3 |
| Dragging onto a shortcut that reached an offline location through a local symbolic link | 1.2.4 |
| Deleting a desktop file, or hovering the Recycle Bin, with a mapped network drive offline | 1.2.5 |
The last one is instructive: the Recycle Bin query was asking about all drives from a notification thread, so one sleeping NAS could stall the application. Scoping the query to local fixed drives fixed it. The full story is in The same bug, five times: offline network locations.
What can still be slow#
Honestly:
- The first paint on a very large desktop. Boards appear fast; icons take as long as the shell takes.
- A genuinely unreachable target. Work is off the interface thread, so the application stays responsive, but the icon or tooltip that needs that target cannot appear until Windows answers.
- Another program hammering the desktop folder. A sync client rewriting many files produces many change notifications, and DeskDrawer honours them.
Measuring it yourself#
There are no benchmark figures on this page because a number produced on the developer's machine tells you nothing about yours, and a marketing figure is worth even less. Task Manager will show you DeskDrawer's actual CPU and memory on your desktop, which is the only measurement that matters. See Memory usage for what to expect and why.