The app that was slowing down every other app on my machine

You have probably run into the talk-and-it-types apps by now. Press a key, speak, and your words land as text in whatever you had open. Select a paragraph, press another key, and a natural voice reads it back to you. That whole category went mainstream over the last year or two, and a lot of people lean on it every day now. The nice part is you no longer have to rent one from a cloud service. Speech recognition and neural voices all run fine on your own hardware, which means you can build a private, self-hosted version that costs nothing a month and never sends your voice anywhere. Mine is called VoiceType. It also does a trick I am fond of: it translates as it reads, so I can select an English article and have it spoken back to me aloud in Spanish, French, or Polish. If you want the tool itself, I wrote it up here.

So. The read-aloud in VoiceType felt slow. Not broken, just slow. I select a paragraph, press F2, and a second or two later a voice reads it back to me. This post is about the two and a half seconds I could not explain, and where they turned out to be hiding.

The whole F2 trip is two jobs. Grab the text I selected, then turn that text into speech. Kokoro runs on my own box now, and synthesis had gotten close to instant, first audio inside a couple hundred milliseconds. Yet the whole thing still took about three seconds start to finish. If the speaking part was fast, something else was eating the rest. So I put a stopwatch on each phase and watched.

The grab. Just getting the selected text out of whatever app had focus was taking about 2.3 seconds. To read three words off the screen.

The clue that cracked it

Here is the part that should have told me sooner. The grab took the same 2.2 seconds no matter where I ran it. Telegram, a browser, VS Code, a plain Notepad window. Not roughly the same. The same, to within a rounding error, every single time.

Now, apps are not that polite to each other. Telegram and VS Code do not independently land on the exact same delay for the same operation. When one app is slow, you get that one app's number. When every app on the machine is slow by the identical amount, they are not the thing that is slow. Something they all share is. And the only thing all of them had in common that afternoon was me.

What VoiceType was actually doing

To grab a selection without a proper accessibility hook, you fake being the user. You send Ctrl+C, then read the clipboard. Simple enough, except I did one tidy little thing first. Before copying, I cleared the clipboard, so a fresh copy would be easy to tell apart from whatever was sitting there from before.

That clear is where it all went wrong.

VoiceType is a C# app, and the WinForms call to empty the clipboard, Clipboard.Clear(), does not just wipe it. It puts an empty clipboard object onto the clipboard, and that object is owned by the thread that called it, which in my case was VoiceType's capture thread. Owning the clipboard is a promise. Windows expects the owner to answer questions about it, and to answer them on a thread that is pumping window messages.

My capture thread cleared the clipboard and then went to sleep, waiting for the copy to land. It was not pumping anything. So every other app that tried to touch the clipboard, including the very Ctrl+C I had just sent, had to go ask the current owner for permission first. The current owner was me, asleep at the wheel. They waited. Windows eventually gave up on the unresponsive owner and let them through, and eventually was a bit over a second, every time, in every app.

That is why the number was so flat. It was never the app I was copying from. It was a timeout on a question VoiceType refused to answer. My little dictation tool had appointed itself gatekeeper of the system clipboard and then stopped taking calls. Anything on the machine that tried to copy while F2 was working got held up behind it.

I sat with that one for a minute. The app was not the victim of a slow system. It was the reason the system was slow.

The fixes, in order

Once you can see it, it comes apart in a few pieces.

First, stop owning the clipboard. Instead of the friendly WinForms clear, I empty it the low-level Win32 way, opening the clipboard with no owner window and emptying it there. Nothing gets left behind with my name on it, so nothing else has to wait on me.

Second, wait for the key to come up. A copy sent while F2 is still physically held down gets swallowed, because the Ctrl in my synthetic keystroke collides with the key the user is still pressing. So the app now waits for the real, physical release before it sends Ctrl+C. Sounds obvious written down. It was not obvious at 1am :)

Third, watch the right signal. The clipboard keeps a change counter that ticks up every time its contents change. The old code retried by calling a clipboard read in a loop, and that call had its own internal retry that quietly blocked for about 1.7 seconds before returning. So I was waiting for the copy inside a function that was already waiting, badly. Now the retry watches the change counter directly. The moment it ticks, the copy has landed and I read it. No blind polling of a call that blocks on its own.

Fourth, speak first, tidy up after. Part of being a good citizen is putting the user's original clipboard back the way it was. There is no reason that restore has to happen before the voice starts talking. So the speaking kicks off, and the clipboard gets restored after, off the critical path where nobody is waiting on it.

The numbers

The grab went from 2.3 seconds to about 190 milliseconds. The full F2 trip, from the moment I press the key to the first spoken word, went from roughly three seconds to somewhere between half a second and eight tenths of a second, with Kokoro running locally. It feels like a different app now. Select, press, it talks.

And the rest of the machine stopped hitching whenever I used it, which I only noticed in hindsight, because I had gotten used to blaming everything else.

That is the part I want to keep. For days I was profiling the wrong programs, half-convinced Telegram or the browser had gone slow on their own. The tell was there the whole time, sitting in the data. When every app is slow by the exact same constant, the common factor is you. Not the apps, not the OS, you. The fix took an evening. Seeing that I was the problem took a stopwatch on every phase and a change counter I could actually trust, because my own gut kept pointing at everyone else.

Thanks for reading.