Memory usage
What DeskDrawer holds in memory, the choices that keep that small, and how to measure it on your own machine.
What is actually held#
| In memory | Why |
|---|---|
| The board layout | It is the application's entire state, and it is small |
| Resolved icons (Icon cache) | Re-resolving on every redraw would be visibly slow |
| One window per board | Boards are windows |
| The .NET runtime | It is a .NET application |
There is no file index, no thumbnail database, no search cache and no history.
Choices that keep it down#
- Workstation garbage collection, non-concurrent. Server GC allocates per-core heaps and a background collector thread — sensible for a server, waste for a tray utility that allocates very little. Configured explicitly in the project rather than left to default.
- No satellite resource assemblies. The application ships English resources only, which is possible because the interface is icons rather than sentences — see Languages.
- A bounded, in-memory icon cache. Never written to disk, so it cannot grow across sessions or go stale.
- No plugin host. Nothing third-party is ever loaded into the process.
What makes it bigger#
Mostly your desktop. Memory scales with the number of desktop items and their Icon size, because that is what the icon cache holds. A desktop of 30 items and a desktop of 500 are not the same application in memory.
Why there is no number on this page#
Because any figure quoted here would be measured on one machine with one desktop, and yours differs in the variables that actually drive the number: how many items you have, at what icon size, on how many monitors, with which cloud client.
Measure it directly instead — Task Manager → Details → DeskDrawer.exe. That figure is true for your machine, which is more than a number on a marketing page can be.