What watching the pasteboard costs
macOS publishes no notification when the clipboard changes. There is no callback to register, so every clipboard manager polls. It reads one integer, NSPasteboard.general.changeCount, a few times a second, and compares it to the last value it saw. If the number has not moved, nothing happens at all.
That is the entire watching mechanism. If a manager costs you real CPU while you are not copying, the polling is not the reason.
Work only starts when the number changes. That work is reading the pasteboard, deciding what type the content is, and writing it somewhere. It happens once per copy, and copies are rare on the scale a CPU cares about.
Where the cost actually hides
Images. A screenshot is a few megabytes. Store those bytes inside the database next to your text rows and the file grows fast. Every query then drags more data around, and reads get slower as the history fills.
Getting this right took me longer than any other part of the app. Making a pasted image survive a restart at all was harder than it looks. The working answer was to keep image bytes in separate files named by their hash, deduplicated, with the database holding only a reference.
Hashing and writing on the wrong thread. Once images go to files, something has to hash several megabytes and write them to disk. Do that on the main thread and you have built a stutter into the act of copying, which is the one moment the user is watching. That path has to move off the main thread for anything large, and the pasteboard read itself has to stay on the main thread, because it is not thread-safe. Splitting those correctly is fiddly.
The window here reads one page at a time out of the database, with the search and the filters pushed down into the query. An earlier version loaded an index of everything into memory first, which was fine at a few hundred items and awful at several thousand.
Two separate numbers matter for this. How many clips the popup keeps in memory, and how many the database keeps on disk. Confusing them is how a manager ends up holding your whole history in RAM to draw a list of ten rows.
Text recognition. Reading text out of every copied image costs real CPU, on the copy, whether or not you will ever search for that text. Doing it on demand instead of on every copy is the difference between a feature and a tax.
Rich text. Parsing HTML into styled text on macOS goes through an old WebKit-based importer. The first call in a process loads that whole framework, so the first rich preview after launch is noticeably slower than every one after it. The fix is unglamorous: warm it up quietly after launch, then cache the result per item.
Cleanup on the hot path. My own worst offender. A maintenance pass that looked for orphaned image files was being called from the retention routine, which ran on every single copy. It scanned every stored item and every file in the blob folder to find files nothing referenced. With a full history, that added a visible delay to copying, every time. It now runs at launch and when you clear the history, and nowhere near a copy.
What people actually notice
Responsiveness beats resource use for how fast an app feels. The popup either appears the instant you press the shortcut or it does not. A millisecond of CPU saved somewhere invisible does not buy that back.
The hardest bug I have had was in this category. The popup would not close when I released the keys, and I spent three hours on it before working out that I was fighting the way macOS delivers keyboard events. Nothing about that was a performance problem in the usual sense. It made the app feel broken anyway.
Where this argument stops
A bundled browser engine is a different conversation. An app that ships its own copy of a browser to draw a list has a memory floor before it does anything useful, and it is always running. I have not audited other clipboard apps' bundles, so I am not going to name any of them or quote numbers I did not measure.
Accessibility-based pasting has a real cost, and it is not CPU. Simulating a paste keystroke needs an accessibility permission. That is a security decision you are making, and it deserves more attention than a megabyte either way.
Check it yourself instead of believing me. Open Activity Monitor, sort by CPU, and leave it for a minute while you work. If a clipboard manager is your problem, it will be obvious. Usually it is a browser, an indexer, or a sync client.
Where mine landed
Klipto is one native binary, around 11 MB installed, with no bundled runtime. That is a size I can verify rather than a benchmark I cannot, and I would rather give you the former.
Four choices carry the speed. Image bytes live in deduplicated files instead of the database. Hashing and writing move off the main thread for large payloads. The popup draws from a small in-memory buffer while the full history pages straight out of the database. Text recognition runs on demand. Retention limits by age and by total size give the database a ceiling you picked.
Maccy is free, open source and about 1.6 MB, and it is fast because it does less. That is a legitimate trade and sometimes the right one.