← Back to Blog

Troubleshooting | Jun 18, 2026 | 7 min read

How to Measure a Clipboard App's Idle RAM and CPU Yourself

By Mohit Sehrawat

How to Measure a Clipboard App's Idle RAM and CPU Yourself — Edge Drop Guide

Vendor claims about RAM and CPU usage are easy to doubt, and they should be. The numbers are usually best-case, measured on a clean test machine with no other apps running, and they rarely match what a user sees on their own machine. The honest answer is to measure the cost yourself, with a methodology that is repeatable and that you control. This guide walks through how to measure a clipboard manager's idle RAM and CPU on Windows, using only built-in tools, in a way that produces numbers you can trust and compare.

For the related discussion of why the numbers matter, see does hardware acceleration help a tiny overlay and how much RAM a clipboard manager should use.

What "idle" means

The single most important thing to define before measuring is what "idle" means. A clipboard manager is not idle when it has just been launched — it is still warming up its database, registering hotkeys, and seeding the clipboard state. It is not idle when it has just processed a copy event — the worker thread that hashed and stored the item is still running. It is idle when it has been running for a while, has processed no recent events, and is doing nothing but waiting for the next clipboard change.

A useful definition of idle: the app has been running for at least 60 seconds, no copy event has occurred in the last 30 seconds, and no interaction (hover, click, hotkey) has occurred in the last 30 seconds. Under those conditions, the app's RAM and CPU should be at their steady-state baseline.

The 60-second settle window matters because of garbage collection. Electron and .NET apps both have generational garbage collectors that release memory in batches, not continuously. An app that has just launched may report 200 MB of RAM and settle to 130 MB after the first GC pass. Measuring before the settle produces a misleadingly high number.

The methodology

The methodology below uses only Task Manager and a stopwatch. No third-party tools are required.

Step 1: Set up the measurement environment

  1. Reboot the machine. This clears any leftover state from previous runs.
  2. Log in. Wait 60 seconds for the OS to settle.
  3. Open Task Manager. Switch to the Details tab.
  4. Right-click any column header, choose Select columns, and add:

- Memory (private working set) — the most honest measure of "how much RAM this app is using" - CPU time — cumulative CPU seconds, useful for catching background work - I/O reads and I/O writes — useful for catching background disk work

  1. Sort by name. Find the clipboard manager's process(es).

Step 2: Launch the clipboard manager

If the clipboard manager is set to launch at startup, it should already be running. If not, launch it manually.

Note the time. Wait 60 seconds. Do not interact with the clipboard manager or copy anything during this window.

Step 3: Record the baseline

After 60 seconds, record:

  • Memory (private working set) for each of the app's processes. An Electron app typically has three to five processes: the main process, the renderer, the GPU process, and possibly utility processes (network, audio, storage). The total RAM is the sum.
  • CPU time for each process. Note the cumulative seconds.
  • I/O reads and I/O writes for each process. These are cumulative byte counts.

Step 4: Wait another 60 seconds and re-measure

Wait another 60 seconds. Do not interact with the app. Re-record the same numbers.

The difference in CPU time between step 3 and step 4 is the app's idle CPU usage. If CPU time went from 12.3 seconds to 12.4 seconds over 60 seconds, the app is using 0.1 seconds of CPU per minute, or roughly 0.17% of one core. That is a healthy idle.

The difference in I/O reads and writes is the app's idle disk usage. A healthy clipboard manager should have near-zero idle I/O.

The difference in RAM should be near zero. If RAM is climbing over the 60-second window, the app has a memory leak or is caching aggressively. Investigate before trusting the baseline.

Step 5: Repeat under load

To get a complete picture, repeat the measurement under three conditions:

  • Idle — as above, no interaction.
  • Active copy — copy a small text item every 5 seconds for 60 seconds. Record the peak RAM and CPU.
  • Large image copy — copy a 20 MB screenshot. Record the peak RAM and CPU for 30 seconds afterwards.

The peak under load is the worst case; the idle is the steady state. Both matter. A clipboard manager that uses 130 MB idle and 250 MB during a large image copy is honest about both numbers; a vendor that reports only the idle is omitting the load cost.

Common measurement mistakes

  • Measuring "Memory (working set)" instead of "Memory (private working set)." The working set includes shared memory that is also counted in other processes' working sets, which double-counts shared libraries. The private working set excludes shared memory and is the more honest measure of the app's own contribution.
  • Measuring only the main process. Electron apps have multiple processes; the main process is typically 30–50 MB, the renderer is 60–80 MB, the GPU process is 30–50 MB. Measuring only the main process undercounts by 60% or more.
  • Measuring immediately after launch. The first 30–60 seconds include startup work that is not representative of steady state. Always wait the full settle window.
  • Measuring while other apps are doing work. Windows shares CPU time across all processes; if a background indexer is running, the clipboard manager's CPU time will be artificially low because the indexer is taking the cycles. Reboot, wait, and measure on a quiet machine.
  • Trusting the vendor's number without methodology. A vendor claim of "uses only 50 MB of RAM" is meaningless without knowing what was measured (main process only? all processes? peak or steady-state?). The methodology above is the methodology you should expect vendors to use; if their methodology is different, their number is not comparable.

What to expect for common clipboard managers

Based on publicly available information and typical measurements as of mid-2026, the following ranges are reasonable. Treat these as orders of magnitude, not lab measurements — your machine will differ.

ToolIdle RAM (all processes)Idle CPUNotes
Win+V (built-in)~20–40 MB~0%Part of the shell; cost is shared
Ditto~30–50 MB~0%Native C++ app
ArsClip~10–20 MB~0%Native, very lightweight
CopyQ~80–120 MB~0–1%Qt-based
Edge-Drop~130–160 MB~0–1%Electron-based

The pattern: native tools are lighter; Qt and Electron tools are heavier. This is the cost of the framework, not the cost of the features. For users for whom 50 MB matters, the native tools win; for users for whom the spatial gesture or the scripting matters, the heavier tools earn their keep.

Honest positioning

Edge-Drop, the Windows hover-activated clipboard shelf, is Electron-based and reports typical idle RAM in the 130–160 MB range when all processes are summed. This is honest and verifiable using the methodology above. The shelf does not win on RAM against Ditto, ArsClip, or Win+V; it does not claim to. What it offers is the hover-activated spatial access pattern and the drag-out workflow, which native tray-history tools do not provide. The right trade depends on which side of that trade the user values more. For the full comparison, see edge-drop vs Ditto: hover shelf or tray history and best clipboard manager for low-RAM PCs.

A short checklist

If you are measuring a clipboard manager's idle cost, work through these:

  1. Reboot and wait 60 seconds before measuring.
  2. Use "Memory (private working set)", not "Memory (working set)".
  3. Sum all processes, not just the main one.
  4. Wait 60 seconds after launch before recording the baseline.
  5. Re-measure after another 60 seconds; check for RAM growth (a sign of leak or aggressive caching).
  6. Measure under load (small copy, large image copy) to get peak numbers.

The methodology takes 5 minutes per app and produces numbers you can compare across tools and across machines. Vendor claims are a starting point; your own measurement is the truth.

Background for this constraint is High Refresh Pointers and Hover Dwell Times.

Related reading

Sources

Mohit Sehrawat
Written by Mohit Sehrawat · Author & Software Tester

Mohit Sehrawat is a B.Tech Computer Science Engineering student with a focus on software testing, bug detection, and product quality. He is interested in exploring applications, identifying issues, and improving the overall user experience through thorough testing.

GitHub · LinkedIn

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support

Free · Lightweight · Privacy First
Find us on CodeHype