Repository navigation
Reduce background memory footprint: ~177 MB in the tray, ~500 MB after conversions #119
Description
Summary
Filee stays resident for the Ctrl+drag donut and the Explorer menu, which is great, but the resident footprint grows a lot after use.
Environment: Windows 11 x64, Filee 1.11.0 (self-contained .NET 10), 32 GB RAM, i5-14600K. Numbers below are the process working set (Task Manager's memory) and private commit (PrivateMemorySize64, Task Manager's commit size).
| State | Working set | Private commit |
|---|---|---|
Tray only (--background), 1.5 min after start |
~177 MB | ~86 MB |
| Tray + main window open, ~2.5 min | ~232-248 MB | ~187-215 MB |
| After a few image conversions, still in tray | ~456-503 MB | ~402-441 MB |
| Peak observed | 474 MB | 708 MB |
filee-cli.exe, one small image conversion |
44 MB peak | process exits |
In tray-only mode the process had 174 modules and 39-44 threads. Opening the window brought it to 196 modules and 74 threads; after conversions the same process showed 196-245 modules and 74-83 threads. Memory does not return to the tray baseline after conversions. Since Filee starts with --background at login, this becomes a cost for the whole session.
The 456-503 MB figure comes from a real session with three image conversions, not a controlled benchmark; I can provide repeat measurements if useful.
Why it matters
The conversion pipeline itself looks cheap: filee-cli.exe peaked at 44 MB and exited. The cost seems to be the resident UI stack (Avalonia/Skia/fonts) plus native engines loaded or cached in the GUI process (ImageMagick, PDFium, HWP, HarfBuzz, ...). 400-500 MB is a lot for a feature used a few times a day, and it may grow further with larger or more varied conversions.
Suggested direction
- Keep the always-on part minimal: tray icon, global drag/hotkey detection and the Explorer menu shim. Start the full Avalonia window/donut on demand.
- Load conversion engines lazily and release them after a conversion or after an idle timeout (e.g. 1-5 minutes), returning to the tray baseline.
- Optionally add "Release memory after N minutes idle" / "Quit after conversion" for people who mainly use the context menu.
I understand unloading trades first-conversion latency for memory. An opt-in idle unload or a separate slim background helper would already make Filee much easier to keep running all day.
Related: #111 / #116 cover quitting from the window; this is specifically about the resident memory footprint after conversions.
Activity
flower-fall commentedon Oct 18, 2026
很抱歉，我是一个代码小白，上面是我让AI帮我写的，简单来说，我感觉现在打开这个软件常驻内存200-500M的占用似乎有点太多了，作为一个希望长期使用的功能，我希望其常驻占用可以少一点
在我发现可以通过关闭其后台运行，直接通过右键也能触发软件打开转换格式的时候，我感觉，似乎可以把它的后台内存占用压到一个极低的数值，所以我让AI在我本地做了一个测试，并且提交了一个小的ISSUE
希望可以有帮助，也希望真的可以减少后台内存占用以便让我后台常驻这个软件的时候可以心理压力更小一点
感谢开发者开发出了如此好用的东西
Release the main window in the tray and give memory back when idle
KnifeLemon commentedon Oct 19, 2026
1.12.0 已发布。用和你相同的场景(转换 12 张大图片后回到托盘)测量:
(工作集 / 提交大小) 转换结束并空闲 30 秒后会释放内存,关闭主窗口时会真正释放窗口。剩下的大部分是界面的 GPU 渲染占用,我们会另外研究。感谢详细的测量!