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.
- Nothing held for what is not on screen. Boards hidden in desktop View mode release their drawing surfaces, the selection band frees its bitmap when you let go, and all boards share one menu — since 1.2.9.
- 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 the 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.