Reduce idle memory usage when CrossPaste is running with no active tasks

[roukmoute]

Solution

CrossPaste seems to use a large amount of memory even when it is idle and nothing is actively happening.

On my side, Windows Task Manager shows roughly 583 MB of RAM used by CrossPaste.exe while idle, with no noticeable CPU, disk, or network activity. For a clipboard utility, this feels unnecessarily high and may discourage users from keeping the application running in the background.

It would be great to improve the idle memory footprint of the application.

Possible improvement ideas:

• reduce eager initialization of components that are not immediately needed
• lazy-load heavy modules only when a related feature is actually used
• release caches more aggressively when the app is idle
• add an optional “lightweight idle mode” for background usage
• expose a simple diagnostics/debug view to help identify which parts consume the most memory

A lower idle footprint would make CrossPaste feel much lighter and more suitable as an always-running desktop utility.

Alternatives

Current workaround is basically to quit the application when it is not needed, but that defeats the purpose of a clipboard/background tool.

Another workaround would be to disable some features if there are heavy modules that can be made optional, but from a user perspective it would be much better if the default idle behavior was already more memory-efficient.

Additional context

I can provide a screenshot from Task Manager if that helps.

[guiyanakuang]

Thanks for raising this — it's a fair question and worth a proper explanation.

CrossPaste Desktop is built with Kotlin Multiplatform (KMP), which allows a single codebase to run across macOS, Windows, and Linux. The trade-off is that the desktop target runs on the JVM, which carries inherent memory overhead that native-compiled applications (written in C++, Rust, Swift, etc.) simply don't have. This overhead comes from multiple layers: the JVM runtime itself, the Metaspace for loaded classes, JIT-compiled code cache, thread stacks, and — most significantly for a UI app — the Skia/Skiko native rendering engine, whose memory lives entirely outside the Java heap and is not controlled by the JVM's garbage collector. This is a known, widely-discussed limitation of the JVM-on-desktop approach, and there is currently no practical way to reduce it to the level of a natively compiled binary without abandoning the cross-platform architecture entirely.

That said, I'd offer some perspective on whether this is worth worrying about in practice:

• Modern operating systems are smart about idle memory. Pages that haven't been touched in a while are compressed or deprioritized by the OS memory manager, so CrossPaste sitting in the background with a few hundred MB reserved doesn't meaningfully compete with your active workloads.
• For a rough comparison: a single Google Chrome tab (the Google Chrome Helper (Renderer) process) typically consumes a comparable amount of memory. CrossPaste's footprint is roughly equivalent to having 2–3 browser tabs open — which most of us don't think twice about.

On the roadmap: I'm currently working on a Chrome extension that will act as a lightweight client. For users who are sensitive to the desktop app's memory footprint, this will be a much leaner alternative once it's available.

I understand memory usage is a real concern, especially on lower-spec machines, and I'll keep looking for incremental improvements within the constraints of the current stack. But a dramatic reduction to native-app levels isn't achievable without a fundamental architectural change.