The opposite happens in CMD on Windows, at least in the past.
Applications that wrote a lot to the logscreen were slowed down by it. While writing to stdout is buffered, it seems that the rendering itself runs in the same thread as the application.
Making a selection freezes the terminal and this stops the rendering, allowing the application to run much faster.
Removing the selection (by pressing escape) rerendered the window (and the buffer), and it went back to its original slowness.
To this day I still attempt never to click inside a running cmd / powershell console. Too many times script execution has been halted by this. It is probably something that has been fixed long time ago but I am still a bit paranoid about it.
It isn't a bug, you could actually toggle this behavior. Don't know how the option was called and cannot find it in Windows 11. But it certainly was still there in the latest Win10 build.
I think it was called something like quick edit or similar.
There is even an option to change the behavior so that the window doesn't freeze if you select anything. Batches freeze completely when you clicked anywhere and I found out the hard way.
Probably some feature that John requested because he couldn't read some output quickly enough. I don't understand how this can be the default behavior.
Applications that wrote a lot to the logscreen were slowed down by it. While writing to stdout is buffered, it seems that the rendering itself runs in the same thread as the application.
Making a selection freezes the terminal and this stops the rendering, allowing the application to run much faster.
Removing the selection (by pressing escape) rerendered the window (and the buffer), and it went back to its original slowness.