The raw CPU time used doesn't really matter if it doesn't cause the UI to block. It does for server applications; needing 30% more cores costs 30% more money, which you could use for something else. But for tiny programs that run on your workstation, using 1.3% CPU doesn't cost more than 1% CPU.

You do have to watch out for the case where you can't use all the cores, and GC is blocking actual computation the user wants to perform.

(Also, you're at about 4000 cores when saving 30% buys you another developer. So you have to think about when the right time to unlock that money is, and how much it costs to unlock.)

I've been writing a game in Go. The GC doesn't prevent me from getting a smooth 360 frames per second. 1ms is a substantial pause, but isn't even a missed frame.

> But for tiny programs that run on your workstation, using 1.3% CPU doesn't cost more than 1% CPU.

Especially considering that text editor state changes are dependent on user interaction—it’s not like a video games where the state changes continuously.

The focus on framerates isn’t to account for changes as the user is typing, but rather scrolling. When scrolling through text, is it smooth? Does it tear? For me, that’s what I see when a text editor refers to framerates.

Even still, that constitutes a user event, and not even one that changes the model. Those events presumably come in on the order of tens of milliseconds, so I wouldn't expect this to be a garbage collection problem?