Hacker News Reader

Comment by 3eb7988a1663 | Hacker News Reader

Gutenberg's copy of Moby Dick is 1.2MB[0]. Which is to say the slowest benchmarked terminal could display a paltry ~53 Moby Dicks per second, while shitty gives you ~98 Moby Dicks.

I am not sure how many Moby Dicks I require per second, but it is good to have options.

[0] https://www.gutenberg.org/ebooks/2701

View on HN

Mere 25-30 years ago I saw some very chatty Java builds run faster if the terminal window was obscured or minimized. Slow console output held back the compilers.

In about 2013 I was an intern at Microsoft and my mentor showed me that if you were running something that streamed a lot to the terminal, it would run faster if you covered it with another window (but didn't minimize it, for some reason I don't recall). I was surprised this kind of trick was still a thing.

"A lot" is quite a bit of an overstatement. I don't remember the exact numbers, but my program, which updated stats (about 100 chars + '\r') every 0.1s, was becoming noticeably faster if these stats were disabled. so, the update speed was at most 100 KB/s

I have reduced build times of Java projects on our Jenkins CI by half (like from 15min to 7min) just by disabling extra logging the application did during tests. Logs can be real slow.

Sometimes you want to dump a LOT of debug to the console but not have the console slow down that program. Or you accidentally cat a TB file?

Besides, most screen only show 60 images per second. That's not many Moby Dicks per second.

I can't give a single FPS how much Moby Dicks per second a terminal emulator can handle!

Reply on news.ycombinator.com