The perl motto reads,’There’s more than one way to do it!’. I think that line is pretty much applicable to anything we do on Linux. What comes to your mind when someone mentions Linux? The terminal! Why is it important? Because thats where you run commands in Linux, silly!
Google turned up quite a few alternatives for a Linux terminal emulator. Like any demanding customer, i wanted to know what alternative was the best. So I ran a lame test on all of them, the time they take to print stuff. i know the puritans would argue that memory, cpu usage and [to a far lesser extent] download size are the parameters that decide how good a software is. My counter argument would be the fact that all of that is taken for granted today! Our laptops are more powerful than Crays were a decade ago. So stop whining about those performance metrics, unless an app actually causes your system to hang or use up 90+% of resources! Very machine specific measure, yes. But the relative speeds will probably scale, and thus its a good indicator of how good a terminal emulator is.
Spewed out text is pretty much all the output we get in terminals, our own inputs apart. What if the terminal printing speed was the bottleneck here? Assuming it is, my post should shed some light on whats the best option out there for use.
The various emulators i tested are: gnome-terminal, aterm, the shell inside emacs, guake, rxvt and xterm.
I cat’ed a text file 100 times to create a 30mb text file that contained about 210,000 lines. And used `time cat big_file` on each of the terminals. The value is the average of 5 runs. The results are presented below:
| Terminal | Time(s) |
| aterm | 7.6365 |
| emacs | 92.9118 |
| gnome-terminal | 68.953 |
| guake | 70.4815 |
| rxvt | 9.47 |
| xterm | 12.9122 |
Strangely though, xterm took 40s to do the same job when i had it maximized. I’m guessed it’s probably because it had to manipulate more onscreen text when maximized.
Parting notes, chuck gnome-terminal!
].
.