Overview of terminal emulators
A few words from our translate-bureau: usually everyone wants to translate the latest materials and publications, and we are no exception. But terminals are not something that is updated once a week. Therefore, we translated for you an article by Antoine Bopre published in the spring of 2018: in spite of the solid “age” by modern standards, in our opinion, the material has not completely lost its relevance. In addition, the original is a series of two articles, but we decided to combine them into one big post.
Terminals occupy a special place in computer history, but in recent decades they have been "forced" to literally survive along with the command line against the background of ubiquitous graphical interfaces. Terminal emulators replaced their hardware counterparts , which, in turn, were a modification of systems on punch cards and toggle switches. Modern distributions come with a host of terminal emulators of all shapes and colors. And while many are quietly content with the standard terminal provided by their work environment, some are proud to use frankly exotic software to launch their favorite shell or text editor. But, as we will see from this article, not all terminals were created in the same image and likeness: they vary greatly in functionality, size and performance.
Some terminals have amazing security holes, plus, most have a completely different set of functions, from tabbed interface support to scripting. Although we looked at terminal emulators in the distant past , this article is an update to previous material that will help readers determine which terminal to use in 2018. The first half of the article compares functions, and the second half measures performance.
Here are the terminals I reviewed:
Perhaps these are not the latest versions, since I limited myself to stable builds at the time of writing, which I was able to roll out on Debian 9 or Fedora 27. The only exception is Alacritty. He is a descendant of terminals with GPU acceleration and is written in an unusual and new language for this task - Rust. I excluded web terminals from my review (including those on Electron ), because preliminary tests showed their extremely low performance.
I started my tests with Unicode support. The terminal’s first test was to display the Unicode string from a Wikipedia article : “é, Δ, , ק, م, ๗, あ, 叶, 葉 and 말.” This simple test shows whether the terminal can work correctly around the world. The xterm terminal does not display the Arabic Mem symbol in the default configuration:
By default, xterm uses the classic “fixed” font, which, according to Wiki , has “significant Unicode coverage since 1997.” Something happens in this font that causes the character to appear as an empty frame and only when the text font is increased to 20+ points does the character finally begin to display correctly. However, such a “fix” breaks the display of other Unicode characters:
These screenshots were taken in Fedora 27, since it was she who gave better results than Debian 9, where some older versions of terminals (specifically mlterm) could not work properly with fonts. Fortunately, this has been fixed in later versions.
Now pay attention to the string mapping in xterm. It turns out that the Mem symbol and the subsequent Semitic Qoph belong to RTL ( right-to-left ) scripts, so technically they should be displayed from right to left. Web browsers, such as Firefox 57, correctly handle the above line. A simpler version of the RTL text is the word " Sarah " in Hebrew ( שרה ). The bi-directional wiki page says the following:
Many terminals fail this test: Alacritty, the VTE-derived terminals Gnome and XFCE, urxvt, st and xterm display “Sarah” in the reverse order, as if we spelled this name as “Aras”.
Another problem with bidirectional texts is that they need to be aligned somehow, especially when it comes to mixing RTL and LTR texts. RTL scripts should run on the right side of the terminal window, but what should happen for terminals using LTR English by default? Most of them do not have any special mechanisms and align the entire text to the left (including Konsole). The exceptions are pterm and mlterm, which adhere to standards and align such lines to the right.
The next critical feature that I have determined for myself is protection against insertion. Although it is widely known that spells like:
are push code execution commands, few people know that hidden commands can penetrate the console when copying and pasting from a web browser, even after a thorough inspection. Gianna Horne's test site brilliantly shows how harmless the team looks:
it turns into such a nuisance when pasting from the Horn website into the terminal:
How it works? Malicious code is placed in the <span> block, which is moved from the user's field of vision using CSS.
Bracketed paste mode is clearly designed to neutralize such attacks. In this mode, the terminals enclose the inserted text in a pair of special escape sequences to inform the shell about the origin of this text. So the shell receives a signal that it can ignore special characters that the inserted text may contain. All terminals, up to the venerable xterm, support this function, but insertion in Bracketed mode requires support for a shell or application running on the terminal. For example, software using the GNU Readline (the same Bash) needs a ~ / .inputrc file :
Unfortunately, the Horne test site also shows how to get around this protection by formatting the text itself and prematurely end applying the Bracketed mode to it. This works because some terminals do not correctly filter escape sequences before adding their own. For example, in mine, I could not successfully complete the Konsole tests, even taking into account the correct configuration of the .inputrc file. This means that you can easily get system configuration damage due to an unsupported application or improperly configured shell. This is especially dangerous when entering remote servers, where careful study of the configuration is less common, especially if you have many such remote machines.
A good solution to this problem is the paste confirmation plugin for the urxvt terminal, which simply asks for permission to paste any text containing new lines. I did not find a more secure option for the text attack described by Horn.
A popular feature now is the support for a tabbed interface, which we will define as one terminal window containing a few more terminals. For different terminals this function is different, and although traditional terminals like xterm do not support tabs at all, more modern terminal incarnations represented by Xfce Terminal, GNOME Terminal and Konsole have this function. Urxvt also has tab support, but only if the plugin is used. But in terms of supporting tabs as such, Terminator is the undisputed leader: it not only supports tabs, but can also arrange terminals in any order (see image below).
Another feature of Terminator is the ability to "group" these tabs together and send the same keystrokes to several terminals at the same time, which provides a rough tool for performing bulk operations on several servers simultaneously. A similar feature is also implemented in Konsole. To use this function in other terminals, you must use third-party software such as Cluster SSH , xlax or tmux .
Tabs work especially well in conjunction with profiles: for example, you can have one tab for email, another for chat, and so on. This is well supported by Konsole and GNOME Terminal. Both allow each tab to automatically launch its profile. Terminator also supports profiles, but I could not find a way to automatically launch certain programs when I open a certain tab. Other terminals do not have the concept of a profile at all.
The last thing I will consider in the first part of this article is the appearance of the terminals. For example, GNOME, Xfce, and urxvt support transparency, but have recently phased out support for background images, forcing some users to switch to the Tilix terminal. Personally, I'm happy with just Xresources , which sets the basic background color set for urxvt. However, custom color themes can cause problems. For example, Solarized does not work with htop and IPTraf applications , as they already use their own colors.
The original VT100 terminal did not support colors, and the new ones were often limited to a 256-color palette. For advanced users who style their terminals, shell requests or status bars in some complex ways can be an unpleasant limitation. Gist keeps track of which terminals have True Color support. My tests confirm that st, Alacritty, and VTE-based terminals perfectly support True Color. Other terminals in this regard do not feel very well and in fact do not even display 256 colors. Below you can see the difference between True Color support in GNOME, st and xterm terminals, which do a good job with their 256-color palette, and urxvt, which not only fails the test, but even shows some blinking characters instead them.
Some terminals also analyze text for URL patterns to make links clickable. This applies to all VTE-derived terminals, while urxvt requires a special plug-in that transforms URLs by click or keyboard shortcut. Other terminals I tested display URLs in other ways.
Finally, a new trend for terminals is the scroll buffer option. For example, in st there is no scroll buffer; it is assumed that the user will use a terminal multiplexer like tmux and GNU Screen .
Alacritty also lacks reverse scroll buffers, but support will soon be added due to the "extensive feedback" on this topic from users. In addition to these upstarts, every terminal I’ve checked that I can find supports backward scrolling.
In the second part of the material ( in the original, these were two different articles, - approx. Per. ) We will compare performance, memory usage and delay. But we already see that some of the terminals under consideration have serious shortcomings. For example, users who regularly work with RTL scripts can pay attention to mlterm and pterm, as they cope better with such tasks than others. Konsole also performed well. Users who do not work with RTL scripts can choose something else.
From the point of view of security against the insertion of malicious code, urxvt stands apart because of its special implementation of protection against this type of attack, which seems to me definitely convenient. Those who are looking for any bells and whistles should look at Konsole. Finally, it is worth noting that VTE is an excellent base for terminals, which guarantees color support, URL recognition and so on. At first glance, the default terminal that comes with your favorite environment can meet all the requirements, but let's leave this question open until we figure out the performance.
In general, terminal performance in itself may seem like a far-fetched problem, however, as it turned out, some of them demonstrate a surprisingly large delay for this fundamental type of software. We will also look further at what is traditionally called “speed” (in fact, it is the scroll speed) and the memory consumption by the terminal (with the view that today it is not as critical as it was decades ago).
After a thorough study of the terminal performance, I came to the conclusion that the most important parameter in this regard is the delay size (ping). In his article “We print with pleasure”, Pavel Fatin examined the delay of various text editors and hinted that terminals in this regard may work more slowly than the fastest text editors. It was this hint that led me, ultimately, to launching my own tests and writing this article.
But what is a delay, and why is it so important? In his article, Fatin defined it as “the delay between pressing a key and the corresponding screen update” and cited the “Manual on Human-Computer Interaction” , which states: “The delay in visual feedback on the computer display has an important effect on the typist’s behavior and her satisfaction ".
Fatin explains that such a ping has deeper consequences than just satisfaction: “typing becomes slower, more errors occur, eye and muscle tension increase”. In other words, a large delay can lead to typos, as well as a decrease in the quality of the code, as it leads to an additional cognitive load on the brain. But even worse, the ping “increases the tension of the eyes and muscles”, which, apparently, implies the development of professional injuries in the future ( apparently, the author means problems with the muscles of the eyes, back, arms and, of course, vision, - approx. Per. ) Due to repeated stress.
Some of these effects have been known for a long time, and the results of a study published back in 1976 in the journal Ergonomics say that a delay of 100 milliseconds "significantly worsens the speed of dialing." More recently, an acceptable response time of 10 milliseconds was introduced in the GNOME user guide, and if we go further, Microsoft Research shows that 1 millisecond is ideal.
Fatin conducted his tests on text editors; he created a portable tool called Typometer , which I used to test ping in terminal emulators. Keep in mind that the test was conducted in simulation mode: in reality, we also need to consider the input delay (keyboard, USB controller, etc.) and output (video card buffer, monitor). According to Fatin, in typical configurations it is about 20 ms. If you have gaming equipment, you can achieve an indicator of only 3 milliseconds. Since we already have such fast equipment, the application should not introduce its delay as well. Fatin’s goal is to delay the application up to 1 millisecond, or to achieve dialing without measurable delay , as in IntelliJ IDEA 15 .
And here are the results of my measurements, as well as some results of Fatin in order to show that my experiment is consistent with his tests:
The first thing that struck me was the best response time for older programs such as xterm and mlterm. With the worst register latency (2.4 ms), they showed better results than the fastest modern terminal (10.6 ms for st). No modern terminal falls below the threshold of 10 milliseconds. In particular, Alacritty does not meet the requirements for “the fastest existing terminal emulator”, although its results have improved since the first check in 2017. Indeed, the authors of the project are aware of the situation and are working to improve the display. It should also be noted that Vim using GTK3 is an order of magnitude slower than its GTK2 counterpart. From this we can conclude that GTK3 creates an additional delay, and this is reflected in all other terminals that use it (Terminator, Xfce4 Terminal and GNOME Terminal).
However, differences may not be noticeable to the eye. As Fatin explains: “it is not necessary to be aware of the delay in order for it to have an effect on you.” Fatin also warns of a standard deviation: "Any irregularities in the length of the delay (jitter) create an additional burden due to their unpredictability."
The graph above is taken on pure Debian 9 (stretch) with the i3 window manager . This environment gives the best results in delay tests. As it turned out, GNOME creates an extra ping of 20 ms for all dimensions. A possible explanation for this is the presence of programs with synchronous processing of input events. Fatin cites a Workrave example for this case, which adds a delay by processing all input events synchronously. By default, GNOME is also equipped with a Mutter window manager, which creates an additional level of buffering, which affects ping and adds a minimum of 8 milliseconds of delay.
The next test is the traditional “speed” or “bandwidth” test, which measures how quickly the terminal can scroll through a page, displaying a large amount of text on the screen. The mechanics of the test vary; the original test was to just generate the same text string with the seq command. Other tests include checking by Thomas E. Dickey (the xterm maintainer), which repeatedly downloads the terminfo.src file . In yet another terminal performance review, Den Luu uses a base32 encoded string of random bytes, which is output to the terminal using cat. Luu considers such a test “as useless as it can be imagined” and suggests using the response of the terminal as the main indicator instead. Dickey also calls his test misleading. However, both authors acknowledge that terminal window bandwidth can be a problem. Luu found Emacs Eshell freezing when displaying large files, and Dickie optimized the terminal to get rid of the visual slowness of xtrerm. Therefore, there is still some reason for this test, but since the rendering process is very different from terminal to terminal, it can also be used as a test component for checking other parameters.
Here we see that rxvt and st are ahead ahead of the competition, followed by the much newer Alacritty, which is being developed with a focus on speed. Next come Xfce (the VTE family) and Konsole, which work almost twice as fast. The last one is xterm with an index five times slower than rxvt. During the test, xterm also rippled, it was difficult to see the passing text, even if it was the same line. Konsole turned out to be fast, but at times it was “tricky”: the display hung from time to time, showing the text partially or not displaying it at all. Other terminals displayed strings clearly, including st, Alacritty, and rxvt.
Dickey explains that performance differences are related to the design of scroll buffers in different terminals. In particular, he accuses rxvt and other terminals of “not following the general rules”:
To correct this seeming slowness of xterm, Dickey suggests using the fastScroll resource, which allows xterm to discard some screen updates in order to keep up with the stream. My tests confirm that fastScroll improves performance and brings xterm to the same level as rxvt. This, however, is a rather crude crutch, as Dickey himself explains: "sometimes xterm - like konsole - seems to stop, as it expects a new set of screen updates after some of them have been removed." In this vein, it seems that other terminals have found the best compromise between speed and display integrity.
Regardless of the appropriateness of considering the scroll speed as an indicator of performance, this test allows you to simulate the load on the terminals, which, in turn, allows us to measure other parameters, such as memory or disk usage. Metrics were obtained by running the specified seq test under the monitoring of the Python process. He collected getrusage () counter data for ru_maxrss , the sum of ru_oublock and ru_inblock, and a simple timer.
In this test, ST takes first place with the smallest average memory consumption of 8 MB, which is not surprising when you consider that the main idea of the project is simplicity. Mlterm, xterm and rxvt consume a bit more - about 12 MB. Alacritty has another notable result, which requires 30 MB to work. Then there are VTE family terminals with indicators from 40 to 60 MB, which is quite a lot. Such consumption can be explained by the fact that these terminals use higher-level libraries, for example, GTK. Konsole comes last with an enormous consumption of 65 MB of memory during tests, although this can be justified by its very wide range of functions.
Compared to previous results obtained ten years ago, all programs began to consume significantly more memory. Previously, Xterm required 4 MB, but now - 15 MB just to run. Rxvt has a similar increase in consumption, which now requires 16 MB out of the box. The Xfce terminal takes up 34 MB, which is three times more than before, but the GNOME Terminal requires only 20 MB. Of course, all previous tests were carried out on a 32-bit architecture. At the 2012 LCA, Rusty Russell said that there are many more subtle reasons that can explain the increase in memory consumption. With all this, we are now living in a time when we have whole gigabytes of memory, so we can handle it somehow.
However, I can’t get rid of the feeling that allocating more memory to such fundamental software as a terminal is a waste of resources.These programs should be the smallest of the smallest, should be able to work on any "box", even shoe, if we ever come to the fact that they will need to be equipped with Linux-systems (and you know that it will be so) . But with these numbers, the use of memory will become a problem in the future in any environment when launching several terminals, except for the situation with several of the lightest and most limited in capabilities. To compensate for this, GNOME Terminal, Konsole, urxvt, Terminator, and Xfce Terminal have a Daemon mode that allows you to control multiple terminals through a single process, which limits their memory consumption.
-: , , . , VTE ( 2010 , ). , , , AES256 GCM ( 0.39.2 ). , VTE, …
, VTE , , . , VTE- Daemon-, . , , , - , . VTE (), GNOME. , VTE . , Linux , . - . , xterm mlterm 10 , .
, - Linux . , . , Wayland : Typometer, , , Wayland — . , Wayland , X.org, , - .
Terminals occupy a special place in computer history, but in recent decades they have been "forced" to literally survive along with the command line against the background of ubiquitous graphical interfaces. Terminal emulators replaced their hardware counterparts , which, in turn, were a modification of systems on punch cards and toggle switches. Modern distributions come with a host of terminal emulators of all shapes and colors. And while many are quietly content with the standard terminal provided by their work environment, some are proud to use frankly exotic software to launch their favorite shell or text editor. But, as we will see from this article, not all terminals were created in the same image and likeness: they vary greatly in functionality, size and performance.
Some terminals have amazing security holes, plus, most have a completely different set of functions, from tabbed interface support to scripting. Although we looked at terminal emulators in the distant past , this article is an update to previous material that will help readers determine which terminal to use in 2018. The first half of the article compares functions, and the second half measures performance.
Here are the terminals I reviewed:
Perhaps these are not the latest versions, since I limited myself to stable builds at the time of writing, which I was able to roll out on Debian 9 or Fedora 27. The only exception is Alacritty. He is a descendant of terminals with GPU acceleration and is written in an unusual and new language for this task - Rust. I excluded web terminals from my review (including those on Electron ), because preliminary tests showed their extremely low performance.
Unicode support
I started my tests with Unicode support. The terminal’s first test was to display the Unicode string from a Wikipedia article : “é, Δ, , ק, م, ๗, あ, 叶, 葉 and 말.” This simple test shows whether the terminal can work correctly around the world. The xterm terminal does not display the Arabic Mem symbol in the default configuration:
By default, xterm uses the classic “fixed” font, which, according to Wiki , has “significant Unicode coverage since 1997.” Something happens in this font that causes the character to appear as an empty frame and only when the text font is increased to 20+ points does the character finally begin to display correctly. However, such a “fix” breaks the display of other Unicode characters:
These screenshots were taken in Fedora 27, since it was she who gave better results than Debian 9, where some older versions of terminals (specifically mlterm) could not work properly with fonts. Fortunately, this has been fixed in later versions.
Now pay attention to the string mapping in xterm. It turns out that the Mem symbol and the subsequent Semitic Qoph belong to RTL ( right-to-left ) scripts, so technically they should be displayed from right to left. Web browsers, such as Firefox 57, correctly handle the above line. A simpler version of the RTL text is the word " Sarah " in Hebrew ( שרה ). The bi-directional wiki page says the following:
“Many computer programs cannot correctly display bidirectional text. For example, the Hebrew name “Sarah” consists of the symbols sin (ש) (which appears on the right), then resh (ר) and, finally, heh (ה) (which should appear on the left). ”
Many terminals fail this test: Alacritty, the VTE-derived terminals Gnome and XFCE, urxvt, st and xterm display “Sarah” in the reverse order, as if we spelled this name as “Aras”.
Another problem with bidirectional texts is that they need to be aligned somehow, especially when it comes to mixing RTL and LTR texts. RTL scripts should run on the right side of the terminal window, but what should happen for terminals using LTR English by default? Most of them do not have any special mechanisms and align the entire text to the left (including Konsole). The exceptions are pterm and mlterm, which adhere to standards and align such lines to the right.
Insertion protection
The next critical feature that I have determined for myself is protection against insertion. Although it is widely known that spells like:
$ curl http://example.com/ | sh
are push code execution commands, few people know that hidden commands can penetrate the console when copying and pasting from a web browser, even after a thorough inspection. Gianna Horne's test site brilliantly shows how harmless the team looks:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.git
it turns into such a nuisance when pasting from the Horn website into the terminal:
git clone /dev/null; clear; echo -n "Hello "; whoami|tr -d '\n'; echo -e '!\nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust! \ Here'"'"'s the first line of your /etc/passwd: '; head -n1 /etc/passwd git clone git://git.kernel.org/pub/scm/utils/kup/kup.git
How it works? Malicious code is placed in the <span> block, which is moved from the user's field of vision using CSS.
Bracketed paste mode is clearly designed to neutralize such attacks. In this mode, the terminals enclose the inserted text in a pair of special escape sequences to inform the shell about the origin of this text. So the shell receives a signal that it can ignore special characters that the inserted text may contain. All terminals, up to the venerable xterm, support this function, but insertion in Bracketed mode requires support for a shell or application running on the terminal. For example, software using the GNU Readline (the same Bash) needs a ~ / .inputrc file :
set enable-bracketed-paste on
Unfortunately, the Horne test site also shows how to get around this protection by formatting the text itself and prematurely end applying the Bracketed mode to it. This works because some terminals do not correctly filter escape sequences before adding their own. For example, in mine, I could not successfully complete the Konsole tests, even taking into account the correct configuration of the .inputrc file. This means that you can easily get system configuration damage due to an unsupported application or improperly configured shell. This is especially dangerous when entering remote servers, where careful study of the configuration is less common, especially if you have many such remote machines.
A good solution to this problem is the paste confirmation plugin for the urxvt terminal, which simply asks for permission to paste any text containing new lines. I did not find a more secure option for the text attack described by Horn.
Tabs and Profiles
A popular feature now is the support for a tabbed interface, which we will define as one terminal window containing a few more terminals. For different terminals this function is different, and although traditional terminals like xterm do not support tabs at all, more modern terminal incarnations represented by Xfce Terminal, GNOME Terminal and Konsole have this function. Urxvt also has tab support, but only if the plugin is used. But in terms of supporting tabs as such, Terminator is the undisputed leader: it not only supports tabs, but can also arrange terminals in any order (see image below).
Another feature of Terminator is the ability to "group" these tabs together and send the same keystrokes to several terminals at the same time, which provides a rough tool for performing bulk operations on several servers simultaneously. A similar feature is also implemented in Konsole. To use this function in other terminals, you must use third-party software such as Cluster SSH , xlax or tmux .
Tabs work especially well in conjunction with profiles: for example, you can have one tab for email, another for chat, and so on. This is well supported by Konsole and GNOME Terminal. Both allow each tab to automatically launch its profile. Terminator also supports profiles, but I could not find a way to automatically launch certain programs when I open a certain tab. Other terminals do not have the concept of a profile at all.
Ryushechki
The last thing I will consider in the first part of this article is the appearance of the terminals. For example, GNOME, Xfce, and urxvt support transparency, but have recently phased out support for background images, forcing some users to switch to the Tilix terminal. Personally, I'm happy with just Xresources , which sets the basic background color set for urxvt. However, custom color themes can cause problems. For example, Solarized does not work with htop and IPTraf applications , as they already use their own colors.
The original VT100 terminal did not support colors, and the new ones were often limited to a 256-color palette. For advanced users who style their terminals, shell requests or status bars in some complex ways can be an unpleasant limitation. Gist keeps track of which terminals have True Color support. My tests confirm that st, Alacritty, and VTE-based terminals perfectly support True Color. Other terminals in this regard do not feel very well and in fact do not even display 256 colors. Below you can see the difference between True Color support in GNOME, st and xterm terminals, which do a good job with their 256-color palette, and urxvt, which not only fails the test, but even shows some blinking characters instead them.
Some terminals also analyze text for URL patterns to make links clickable. This applies to all VTE-derived terminals, while urxvt requires a special plug-in that transforms URLs by click or keyboard shortcut. Other terminals I tested display URLs in other ways.
Finally, a new trend for terminals is the scroll buffer option. For example, in st there is no scroll buffer; it is assumed that the user will use a terminal multiplexer like tmux and GNU Screen .
Alacritty also lacks reverse scroll buffers, but support will soon be added due to the "extensive feedback" on this topic from users. In addition to these upstarts, every terminal I’ve checked that I can find supports backward scrolling.
Subtotals
In the second part of the material ( in the original, these were two different articles, - approx. Per. ) We will compare performance, memory usage and delay. But we already see that some of the terminals under consideration have serious shortcomings. For example, users who regularly work with RTL scripts can pay attention to mlterm and pterm, as they cope better with such tasks than others. Konsole also performed well. Users who do not work with RTL scripts can choose something else.
From the point of view of security against the insertion of malicious code, urxvt stands apart because of its special implementation of protection against this type of attack, which seems to me definitely convenient. Those who are looking for any bells and whistles should look at Konsole. Finally, it is worth noting that VTE is an excellent base for terminals, which guarantees color support, URL recognition and so on. At first glance, the default terminal that comes with your favorite environment can meet all the requirements, but let's leave this question open until we figure out the performance.
Continue the conversation
In general, terminal performance in itself may seem like a far-fetched problem, however, as it turned out, some of them demonstrate a surprisingly large delay for this fundamental type of software. We will also look further at what is traditionally called “speed” (in fact, it is the scroll speed) and the memory consumption by the terminal (with the view that today it is not as critical as it was decades ago).
Delay
After a thorough study of the terminal performance, I came to the conclusion that the most important parameter in this regard is the delay size (ping). In his article “We print with pleasure”, Pavel Fatin examined the delay of various text editors and hinted that terminals in this regard may work more slowly than the fastest text editors. It was this hint that led me, ultimately, to launching my own tests and writing this article.
But what is a delay, and why is it so important? In his article, Fatin defined it as “the delay between pressing a key and the corresponding screen update” and cited the “Manual on Human-Computer Interaction” , which states: “The delay in visual feedback on the computer display has an important effect on the typist’s behavior and her satisfaction ".
Fatin explains that such a ping has deeper consequences than just satisfaction: “typing becomes slower, more errors occur, eye and muscle tension increase”. In other words, a large delay can lead to typos, as well as a decrease in the quality of the code, as it leads to an additional cognitive load on the brain. But even worse, the ping “increases the tension of the eyes and muscles”, which, apparently, implies the development of professional injuries in the future ( apparently, the author means problems with the muscles of the eyes, back, arms and, of course, vision, - approx. Per. ) Due to repeated stress.
Some of these effects have been known for a long time, and the results of a study published back in 1976 in the journal Ergonomics say that a delay of 100 milliseconds "significantly worsens the speed of dialing." More recently, an acceptable response time of 10 milliseconds was introduced in the GNOME user guide, and if we go further, Microsoft Research shows that 1 millisecond is ideal.
Fatin conducted his tests on text editors; he created a portable tool called Typometer , which I used to test ping in terminal emulators. Keep in mind that the test was conducted in simulation mode: in reality, we also need to consider the input delay (keyboard, USB controller, etc.) and output (video card buffer, monitor). According to Fatin, in typical configurations it is about 20 ms. If you have gaming equipment, you can achieve an indicator of only 3 milliseconds. Since we already have such fast equipment, the application should not introduce its delay as well. Fatin’s goal is to delay the application up to 1 millisecond, or to achieve dialing without measurable delay , as in IntelliJ IDEA 15 .
And here are the results of my measurements, as well as some results of Fatin in order to show that my experiment is consistent with his tests:
The first thing that struck me was the best response time for older programs such as xterm and mlterm. With the worst register latency (2.4 ms), they showed better results than the fastest modern terminal (10.6 ms for st). No modern terminal falls below the threshold of 10 milliseconds. In particular, Alacritty does not meet the requirements for “the fastest existing terminal emulator”, although its results have improved since the first check in 2017. Indeed, the authors of the project are aware of the situation and are working to improve the display. It should also be noted that Vim using GTK3 is an order of magnitude slower than its GTK2 counterpart. From this we can conclude that GTK3 creates an additional delay, and this is reflected in all other terminals that use it (Terminator, Xfce4 Terminal and GNOME Terminal).
However, differences may not be noticeable to the eye. As Fatin explains: “it is not necessary to be aware of the delay in order for it to have an effect on you.” Fatin also warns of a standard deviation: "Any irregularities in the length of the delay (jitter) create an additional burden due to their unpredictability."
The graph above is taken on pure Debian 9 (stretch) with the i3 window manager . This environment gives the best results in delay tests. As it turned out, GNOME creates an extra ping of 20 ms for all dimensions. A possible explanation for this is the presence of programs with synchronous processing of input events. Fatin cites a Workrave example for this case, which adds a delay by processing all input events synchronously. By default, GNOME is also equipped with a Mutter window manager, which creates an additional level of buffering, which affects ping and adds a minimum of 8 milliseconds of delay.
Scroll speed
The next test is the traditional “speed” or “bandwidth” test, which measures how quickly the terminal can scroll through a page, displaying a large amount of text on the screen. The mechanics of the test vary; the original test was to just generate the same text string with the seq command. Other tests include checking by Thomas E. Dickey (the xterm maintainer), which repeatedly downloads the terminfo.src file . In yet another terminal performance review, Den Luu uses a base32 encoded string of random bytes, which is output to the terminal using cat. Luu considers such a test “as useless as it can be imagined” and suggests using the response of the terminal as the main indicator instead. Dickey also calls his test misleading. However, both authors acknowledge that terminal window bandwidth can be a problem. Luu found Emacs Eshell freezing when displaying large files, and Dickie optimized the terminal to get rid of the visual slowness of xtrerm. Therefore, there is still some reason for this test, but since the rendering process is very different from terminal to terminal, it can also be used as a test component for checking other parameters.
Here we see that rxvt and st are ahead ahead of the competition, followed by the much newer Alacritty, which is being developed with a focus on speed. Next come Xfce (the VTE family) and Konsole, which work almost twice as fast. The last one is xterm with an index five times slower than rxvt. During the test, xterm also rippled, it was difficult to see the passing text, even if it was the same line. Konsole turned out to be fast, but at times it was “tricky”: the display hung from time to time, showing the text partially or not displaying it at all. Other terminals displayed strings clearly, including st, Alacritty, and rxvt.
Dickey explains that performance differences are related to the design of scroll buffers in different terminals. In particular, he accuses rxvt and other terminals of “not following the general rules”:
“Unlike xterm, rxvt did not try to display all the updates. If he falls behind, he will discard some updates to catch up. This had a greater effect on the imaginary scroll speed than on the organization of internal memory. One drawback was that the ASCII animation was somewhat inaccurate. ”
To correct this seeming slowness of xterm, Dickey suggests using the fastScroll resource, which allows xterm to discard some screen updates in order to keep up with the stream. My tests confirm that fastScroll improves performance and brings xterm to the same level as rxvt. This, however, is a rather crude crutch, as Dickey himself explains: "sometimes xterm - like konsole - seems to stop, as it expects a new set of screen updates after some of them have been removed." In this vein, it seems that other terminals have found the best compromise between speed and display integrity.
Resource consumption
Regardless of the appropriateness of considering the scroll speed as an indicator of performance, this test allows you to simulate the load on the terminals, which, in turn, allows us to measure other parameters, such as memory or disk usage. Metrics were obtained by running the specified seq test under the monitoring of the Python process. He collected getrusage () counter data for ru_maxrss , the sum of ru_oublock and ru_inblock, and a simple timer.
In this test, ST takes first place with the smallest average memory consumption of 8 MB, which is not surprising when you consider that the main idea of the project is simplicity. Mlterm, xterm and rxvt consume a bit more - about 12 MB. Alacritty has another notable result, which requires 30 MB to work. Then there are VTE family terminals with indicators from 40 to 60 MB, which is quite a lot. Such consumption can be explained by the fact that these terminals use higher-level libraries, for example, GTK. Konsole comes last with an enormous consumption of 65 MB of memory during tests, although this can be justified by its very wide range of functions.
Compared to previous results obtained ten years ago, all programs began to consume significantly more memory. Previously, Xterm required 4 MB, but now - 15 MB just to run. Rxvt has a similar increase in consumption, which now requires 16 MB out of the box. The Xfce terminal takes up 34 MB, which is three times more than before, but the GNOME Terminal requires only 20 MB. Of course, all previous tests were carried out on a 32-bit architecture. At the 2012 LCA, Rusty Russell said that there are many more subtle reasons that can explain the increase in memory consumption. With all this, we are now living in a time when we have whole gigabytes of memory, so we can handle it somehow.
However, I can’t get rid of the feeling that allocating more memory to such fundamental software as a terminal is a waste of resources.These programs should be the smallest of the smallest, should be able to work on any "box", even shoe, if we ever come to the fact that they will need to be equipped with Linux-systems (and you know that it will be so) . But with these numbers, the use of memory will become a problem in the future in any environment when launching several terminals, except for the situation with several of the lightest and most limited in capabilities. To compensate for this, GNOME Terminal, Konsole, urxvt, Terminator, and Xfce Terminal have a Daemon mode that allows you to control multiple terminals through a single process, which limits their memory consumption.
-: , , . , VTE ( 2010 , ). , , , AES256 GCM ( 0.39.2 ). , VTE, …
Conclusion
, VTE , , . , VTE- Daemon-, . , , , - , . VTE (), GNOME. , VTE . , Linux , . - . , xterm mlterm 10 , .
, - Linux . , . , Wayland : Typometer, , , Wayland — . , Wayland , X.org, , - .
All Articles