Typing with pleasure
In this article, I explore the human and machine aspects of typing delays (typing or “input lag”) and present experimental data on latency when working with popular text and code editors.
More recently, Delay has become a hot topic in the computer world - now there are low-latency keyboards, 144 Hz monitors, special technologies that reduce latency (such as FreeSync or G-Sync ), communities interested in this and so on and so forth. Of course, part of this fashion was created by marketing, but the truth is that a small delay has become possible and desirable.
Obviously, gamers are the first to benefit from such improvements. In some areas, such as virtual reality , latency is a decisive factor, even when it comes to one millisecond. But what about programmers? Do we need to “print with pleasure” in order to “develop with pleasure”? Let's figure it out.
Content:
')
1. Human side
1.1. Feedback
1.2. Motor skill
1.3. Internal model
1.4. Multisensory integration
1.5. Effects
2. Machine side
2.1. Input delay
2.2. Processing delay
2.3. Output delay
2.4. Full delay
3. Comparative tests of editors
3.1. Configuration
3.2. Methodology
3.3. Windows
3.4. Linux
3.5. Virtualbox
4. Conclusions
5. References
The delay in typing is the time interval between pressing a key and the corresponding screen refresh. It sounds simple, but make no mistake: its impact on the keyboard input process is rather complicated, since such typing is an amazing manifestation of coordinated actions of our body and nervous system (at least from a technical point of view).
Let's start with the basics - is it worth it at all to worry about the delay? We do not have any hurry, we can just print what is required, and check the result later. A few seconds does not solve anything, right? Not really.
A person does not “just type” what he wants; we need feedback to fulfill this task, since our feelings form the so-called closed loop control with our movements. A visual image is not only the result of input; It is an integral part of the process.
The more complete feedback we have when working with the keyboard (typing), the better. In principle, you can print with your eyes closed. We can continue typing, even if we plug our ears, relying only on the tactile sensations of the fingers. However, if we block this last feedback channel, then keyboard input will become impossible. Since the visual form of the sensation is dominant (information from other senses usually adapts to the vision) and is the only way to obtain reliable data on input errors, visual feedback is of great importance.
Reducing the delay leads to a “shortening” of the feedback loop, making the input easier, with greater speed and accuracy. So far so good, but where is the reasonable border? In the end, a person reacts incredibly slowly - “the way there and back” from feelings to consciousness and then back to the muscles takes about 200 ms! Undoubtedly, the reaction can be trained, and it is different in people, but some relatively small delay, like, for example, 100 ms, seems to be a good option, isn't it? Not at all.
Remember your first attempts to use a computer keyboard. Most likely, it took you minutes to press the proper key and then check the result on the screen; this process required all your concentration. However, months and years have flown by, you are now typing amazingly quickly and semi-automatically on the keyboard - you are no longer thinking about any specific keys and, perhaps, don't even look at the keyboard at all ( “blind typing ” ). Practice affects. This process is called “the acquisition of motor skills” (or the acquisition of motor skills ( motor learning )). When the skill reaches the autonomous phase , the task can be performed “automatically” without attracting any attention to its implementation.
Formally speaking, typing (typing on a keyboard) is a process of driving control carried out by a person’s motor system . Since typing (typing on the keyboard) is fine motor skills (coordinated movements of small muscles occur), it is highly dependent on feedback . However, this feedback is processed at the subconscious level, so we will not necessarily be aware of the delay, while experiencing a serious negative impact. The reaction time of a person is important only for correcting errors.
But even semi-automatic processes are limited by visual delay (pdf-file), and any feedback is good only if we can use it. The human vision system takes about 40 ms to process the input. This value also depends on many factors, on a particular person and can be improved by training. We conclude: a delay of less than 20 ms would be acceptable, right? Not really.
First of all, let us clarify that any “external” delay is added to the visual delay, and not superimposed on it, i.e. any delay matters. But one can argue that a value of about 20 ms is still relatively small. Good, but a person’s motor system knows a few dexterity tricks to react faster.
To counteract the input delays in sensory organs and the nervous system, the human movement control system uses a special nervous process known as the internal model . This process can imitate the response (reaction) of the controlled system even before receiving feedback signals - the use of advanced process modeling . Additional inverse model is designed to predict the response (reaction) of the controlled system based on the current feedback.
The delay does not affect the feedback loop directly; it affects, rather, the internal model of the printing process. The direct and inverse models are used in combination with some internal feedback circuits, forming a nonlinear system . As a result, even small delays in feedback signals can lead to significant disruptions when typing on the keyboard (typing).
Separate from the internal model, there is another process that is adversely affected by visual delay — multisensory integration .
The visual image is not the only type of feedback when typing on the keyboard: we can also hear sounds when pressing keys, feel pressure on our fingers, perceive the position of our hands and fingers (so-called proprioception ).
Each of these sensations is processed separately, and the nervous system determines whether or not to use these or other groups of signals. This task is known as the problem of binding and is already a challenge in itself (see, for example, multi-sensory illusions ). When the brain receives exposure from most senses immediately, and the image arrives with some additional delay, this complicates the situation even more.
The nervous system may somewhat adapt (pdf-file) to the constant delay of visual feedback (although not ideal), but any irregularities in the delay time (so-called jitter) create additional problems due to their inherent unpredictability.
There are several illustrative examples from other areas where the delay of the feedback signals can cause worse consequences than its absence, to the point where the initial activity becomes impossible at all: if you play on a MIDI keyboard through a computer, then the delays are 20-30 ms is enough to violate your actions (one article (pdf-file) states that sound delay is important even for 1 ms); another good example is the so-called. SpeechJammer (pdf-file) (“chattering fighter”), which uses a feedback sound delay of approx. 200 ms, temporarily disrupting a person’s ability to speak.
Put together the key points:
• Typing (typing on the keyboard) is a complex semi-automatic process that requires years to master.
• In principle, the printing process can be influenced by millisecond delays in visual feedback.
• It is not necessary for consciousness to perceive the presence of a delay, so that, nevertheless, it negatively affects you.
• People vary greatly in susceptibility and tolerance to delay.
But how exactly does the delay affect the typing process (typing on the keyboard)? There are several possible effects:
• Printing slows down.
• The number of errors and their edits increases.
• Eyes get tired more (because the vision system is overloaded).
• Muscles get tired more (as movement control becomes less certain).
• The process requires more informed attention.
The exact effect of the delay depends on many factors, such as the specific distribution of the delay, the hardware used (keyboard, monitor), the content of the editor (text or code), the main activity (insertion / editing), the printing method (regular / blind printing), the specifics your vision and your motor skills, personal preferences, etc.
Needless to say, the possible impact of the delay is hardly pleasant. The good news is that it works in both directions, i.e., by reducing the visual delay, we can, in general, improve many aspects (here we are talking not only about the printing speed itself)
The results obtained are generally consistent with available research data. If there is a desire to get acquainted with this subject more deeply, then one can look at some books and scientific articles containing data on the effect of delay and on the role of visual feedback on the printing process, for example:
• Cognitive aspects of professional typing
• The role of visual feedback from the screen and hands in professional typing (pdf-file)
In particular, it is worth quoting the following ( source ):
Let's now look at the side of the car to find out how we can improve the situation with a delay.
What happens between the moment a key is pressed and the moment a character appears on the screen? It turns out that there are so many different things, and everything takes time. Is it possible to simply buy a top-end computer in order to ensure quiet typing? This will help, but only to some extent, since many parts of this process are independent of the central and / or graphics processor. Take both pills and I will show you how deep the rabbit hole goes (for even what follows is only part of the whole truth).
The delay in printing can be divided into the following components:
• Input delay (keyboard)
• Delay processing (software)
• Output Delay (Monitor)
Consider each component more carefully.
First, let's figure out how a regular non-gaming USB keyboard handles our input. Such keyboards are used most widely now both on desktop computers and on laptops.
Keyboard scan
A regular keyboard contains more than 100 keys, which is quite a lot. To minimize the number of wires and inputs of the control processor , the key switches are usually connected in a matrix circuit , i.e. "Rows" and "columns" of wires intersect. Due to this, the number of wires and inputs can be reduced from “x * y” to “x + y” (for example, from 121 to 22). The consequence of this approach is that the control processor cannot read the state of all keys at the same time - it must periodically scan them with a constant frequency, which leads to some delay. The typical scan rate of the array is 1,000 Hz, so the maximum delay associated with scanning is 1 ms (the average is 0.5 ms).
Contact Bounce
Regardless of the type of keyboard, the key switches are mechanically imperfect and subject to contact bounce — instead of “pure” operation, the switch quickly goes from the “on” state to the “off” state and back several times before it stops. Chatter duration depends on switching technology; for example, for Cherry MX devices, as stated, it is less than 5 ms. Although the exact probability distribution is unknown, but based on the relevant empirical data , it is possible to take a bounce duration of about 1.5 ms.
Eliminate contact bounce
Since the polling frequency is quite high and because of this the bounce can be interpreted as a few keystrokes, the keyboard control processor performs the so-called. eliminating contact bounce , averaging signals over a time interval sufficient to obtain a reliable result. This filtering introduces an additional delay, depending on the firmware of the microcontroller. Since manufacturers, in general, do not report the characteristics of their microprograms, then we consider a typical deblocking algorithm and assume that filtering adds approx. 7 ms delay; so The maximum "time to eliminate bounce" is approx. 12 ms and average approx. 8.5 ms
USB survey
Since USB is a bus controlled by the host computer, the keyboard must wait for a request from that computer to send the registered keystroke data (the keyboard control processor places the collected events in the output buffer). Although USB devices request the required polling rate during initialization (up to 1,000 Hz), operating systems typically use 125 Hz for both low-speed and full-speed (USB1.x) devices; therefore, the maximum delay associated with polling is 8 ms (the average is 4 ms). It should be remembered that often you can increase the frequency of polling manually.
USB conversion
Some time is also required for data conversion. For both low-speed and full-speed devices, the shortest conversion time is 1 ms. In high-speed devices (USB2) this time is much less - approx. 0.001 ms (by the way, there is an excellent article on the suitability of USB for real-time systems (pdf-file)). To minimize data conversion time, it is recommended not to connect broadband USB devices (such as, for example, drives, sound cards, webcams) to the same USB controller / hub to which your keyboard is connected.
So, let's collect the delay values for a typical keyboard:
These results, in general, correspond to some experimental results on measuring the delay caused by the keyboard.
Is it possible to do better? Of course, easy! Use a professional keyboard:
• switches with a short bounce time (some are even optical )
• high scanning frequency of the matrix
• adaptive debounce algorithm
• customizable firmware
• USB2 for quick polling and low latency conversion
All this can significantly reduce both the maximum and the average value of the keyboard delay. For example, when I purchased the Kinesis Advantage keyboard, I immediately sensed the difference from my previous “regular” keyboard.
Gaming keyboards go even further - if you are a supporter of an uncompromising solution, then you should consider something like Cherry's RealKey technology , in which the key reading goes through analog inputs (and not digital); the delay is almost zero.
Processing delay is the delay between receiving an input signal from the keyboard and generating an image of the entered character in a video frame. Simply put, this is a delay inside the computer itself.
It should be remembered that the processing delay is not determined only by the performance - theoretically, it is possible to have a system delivering 300 FPS, with a “delay” of 5 seconds after entering. In particular, palletizing and buffering are often an attempt to achieve higher performance due to latency.
While conceptually there are many different sources of processing delay, in practice they are so closely related to the use of an editor that all parts are usually measured together (for experimental data, see the next chapter).
operating system
After the USB host (“USB port” of the computer) receives data from the keyboard, it initiates a hardware interrupt so that the software driver in the operating system can read the received data through the host controller interface (usually via PCI or PCIe ). This data is then processed by the human-machine interface (HID) subsystem in the OS, which ultimately results in placing the key pressed event (of the WM_KEYDOWN type) into the message queue of the operating system. After this, the event is sent by the event loop to the window of the active application.
All these actions require some time, but it is negligible for our purpose (typing on the keyboard). What is important here is that the main operating systems (namely, Windows, Mac, and Linux-based OS) are not real-time systems , so there is no guarantee for the delay value. Both hardware processes (network I / O, storage I / O, etc.) and software multitasking can increase processing time unpredictably (and indefinitely).
By the way, since GUI applications can impose severe restrictions on system latency, there have been many successful attempts to optimize Linux kernel planning specifically for the case of “desktop” use (in particular, through the ulatencyd dynamic optimization system).
For simplicity, suppose that our computer does not have a significant load on keyboard input; then this kind of delay will be less than 1 ms.
Virtual machine
If the text editor / IDE runs on top of the process virtual machine (like the Java JVM or the .NET Framework CLR ), additional delays may occur because their runtime is also not a real-time system (except for special implementations, such as Real time Java ).
Performance by itself does not usually create a problem, but when the JIT compiler or garbage collector is turned on, you can expect some “lag”. JavaScript engines and the Emacs Lisp interpreter also generate this type of delay.
The main virtual machines have improved significantly over many years, however, some preliminary “warm-up” could still be useful to ensure a stable delay.
Editor
This part is the most significant. The editor used can make a major contribution to the delay in typing. Unlike the delays created by the hardware, the maximum delay in the editor is practically unlimited (you can easily stumble upon for 1-2 seconds).
Since the editor is mainly tied to the central processor , it is possible to reduce the delay of the editor using a more powerful machine (it also helps a good graphics processor ). But hope only for power is not entirely justified - it often goes where it is most needed (for example, when you start a development server or process some data in the background). Also keep in mind that even a first-class laptop can be much more sluggish in power saving mode (on battery), so this approach is only partially effective. In addition, it is quite expensive, as you know.
There is a better way - in principle, we don’t need a supercomputer for quiet typing - all we have to do is implement the use of the editor, bearing in mind our goal. Typing in the editor is a relatively simple process, so even computers on a 286 processor provided fairly quick entry. It is quite possible to achieve near-zero printing latency even in a sophisticated modern IDE, which is exactly what zero-delay printing is aimed at in IntelliJ IDEA. For technical details, see my article on low-latency rendering in AWT and Swing (although the Java platform is being considered, key ideas can be extended to most modern operating systems and frameworks for building graphical user interfaces).
Editors / IDEs vary greatly in typing delay. The following chapter contains a large amount of empirical information on the topic.
Rendering pipeline
The central and graphic processor work in parallel and interact through the command buffer , supplemented by the video driver buffer. Most rendering commands are asynchronous. Therefore, they have the full right not to run as soon as the rendering method works. The drawing commands are accumulated in the video driver buffer, then they are packaged and sent to the graphics processor's command buffer (an attempt is made to get a higher frame rate due to the delay). The resulting delay, depending on the combination of hardware / operating system / software interface of the application / video driver, can vary from insignificant to very substantial.
A typical desktop application runs on top of frameworks for building graphical user interfaces, so it is isolated from the underlying rendering pipeline and, thus, from rendering synchronization (rendering). This is usually acceptable, because many desktop applications are not sensitive to latency. However, some actions are extremely sensitive to it (such as typing in an IDE), which is why editors can explicitly “push” commands in the buffer and forcefully render a frame to reduce latency. As an example, see the synchronization job in OpenGL . You can also watch a demonstration material about “pushing through” the conveyor .
Double buffering
In order not to show a partially drawn frame and to present the whole image on the screen at once, many applications turn to the so-called. double buffering - the image is initially prepared in an off-screen “secondary buffer”, and when all graphic operations are completed, the updated image area is transferred to the frame buffer by bit-wise copying or by switching the page . Many frameworks (like Swing ) do double buffering by default.
Needless to say, this extra step leads to an additional delay. The Java documentation says: “If your performance metric is simply the speed at which double buffering or page switching occurs compared to direct rendering, then you may be disappointed. It may turn out that the values of direct rendering will be much higher than those of double buffering, and these, in turn, will be much higher than the page switching. ”
Sometimes double buffering is absolutely necessary; in other cases it is not actually required; therefore, editors should use double buffering cautiously to avoid excessive visual delay. For more information, see the sample buffering costs .
Window manager
Modern applications rarely work in full screen mode; Most desktop environments show each program in a separate window. This task is performed by the so-called. window managers , which can be divided into several classes depending on how the windows are drawn and updated.
, , . ( ), , . : Classic theme Windows, Openbox Linux.
, ( ) . . : Aero Windows, Compiz in Linux.
Relevant empirical data is provided in the next chapter.
Vertical sync
Vertical sync or V-Sync is a method to prevent the image from breaking on the screen , i.e. this state, when the display shows information from several frames in one screen image. The arising distortions are most noticeable on horizontally moving objects with sharp vertical edges (that is, not during printing).
V-Sync ( , V-Sync ). . 17 , — 8 ( 60 ). , , - 4 , ( ). , , 17 .
, V-Sync. V-Sync Windows Aero, Classic theme. V-Sync Linux, , , , .
V-Sync , , - . (. ).
(, / V-Sync):
These delays are much less predictable than delays caused by hardware, and they are very sensitive to computer configuration. In principle, the total processing delay can be either 0-1 ms, or 10 s. That is why theoretical reflections are not enough here and some exact figures are needed - see the extensive empirical data in the next chapter.
How can I improve the situation with delayed processing? There are several ways:
• Low latency editor / IDE
• Powerful computer hardware (central and graphics processors)
• Stacking window manager (Classic Windows theme, Openbox, etc.).
• Lack of vertical synchronization.
Obviously, the editor is of the greatest importance.
, .
( ). ; , ( VGA, DVI, HDMI, DisplayPort ..), . , , - 60 . , , , 17 , — 8 ( , , ).
- , ( «» — ), - . , , - «» ( , ). ( « »). , . , .. (. Prad , , ). Although in the worst case the delay can be 2-3 frames (i.e. up to 50 ms at a refresh rate of 60 Hz), the input lag is mainly in high definition television and not in computer monitors; therefore, it can be assumed that this delay is close to zero for typical monitors. Nevertheless, it is a good idea to turn off all the “image correctors” on your monitor (oddly enough, and overdrive too ).
Response pixel
Pixels LCD display may not respond to changes in the control voltage immediately. The time interval required to change a pixel on the display is called the pixel response time. . , , - (TN, IPS, VA ..). - , , TN - ( ) 4 .
, :
? :
• , .
• 144 (, , 3,5 ).
• , Adaptive-Sync , FreeSync G-Sync ( 240 ) .
. 1-2 .
:
A typical kit consists of a regular non-game keyboard and a standard LCD monitor. The ideal configuration involves a keyboard and monitor (gaming), having a low latency.
The input and output delay components are strictly determined by periodic hardware processes that can be estimated with high accuracy. These delays do not depend on the performance of the central and graphics processors and have predictable upper bounds. The typical average delay of the keyboard and monitor together is about 26 ms, which is not much in itself, but if you add it to the processing delay, the editor delay will be more noticeable. Even the I / O delay in itself already exceeds the threshold of human perception.
/ , , , . ; , . 0-1 .
, , .
, «Typometer» — ( ).
Typometer , . , (.. , , , , ). , , , , , .
Here is the hardware and software configuration used for testing:
Hardware:
• CPU: Intel Core i5 3427U , 1.8 / 2.8 GHz, 3MB cache
• Graphics: Intel HD 4000 (driver v10.18.10.3958)
• Memory : 4 GB DDR3
• Display: 1920 x 1080, 32 bits, 59.94 Hz
Software:
• Microsoft Windows 7 HP x64 SP1 6.1.7601
• Lubuntu Linux 15.10 Desktop amd64
• VirtualBox 5.0.10 on Windows (default settings, full screen mode)
Editors:
• Atom 1.1
• Eclipse 4.5.1
• Emacs 24.5.1
• Gedit 3.10.4
• GVim 7.4.712
• IntelliJ Idea CE 15.0
• Netbeans 8.1
• Sublime Text 3083
, , , . , ( , ); .
, , , . , Notepad () — , .
, . , — Windows , Linux ( Alt+Fn) .
R . ggplot2 .
All editors / IDEs worked with default settings, application windows were maximized.
The editor worked either with an empty text file or with an XML file (more precisely, with a Maven schema ). XML was chosen because it is highlighted in all editors and does not depend on other project files.
Typometer used the following parameters:
• Number of characters: 200
• Delay: 150 ms
• Access: native
• Mode: synchronous
The delay of 150 ms was chosen because it represents the average time interval between keystrokes with my own fairly fast typing (the minimum interval is 40 ms). The exact value does not play a big role, because Typometer in synchronous mode waits for the symbol to appear before pausing and typing the next one.
A classic window manager was used in Windows, because, as mentioned above, compositing implemented in Aero increases rendering delay and forcibly turns on vertical synchronization (tests showed that Aero theme really makes all editors less susceptible). Here is a comparison of GVim tests (one of the fastest editors in general) in the Classic theme and in Aero (dotted lines at 16.68 and 33.37 ms):
The impact of Windows Aero on drawing latency (GVim)
You can see that Aero introduces at least one frame delay (approx. 16.7 ms for a refresh rate of 60 Hz) and leads to time sampling. This hides the internal performance of the editor and distorts the benchmarking process. As I indicated earlier, the video signal delays created by vertical synchronization are slightly less than the delays in the frame buffer, but the average difference is only 4 ms, and the maximum added delay is still 17 ms (for 60 Hz). Since the effect is quite substantial, people often find an added delay “to the naked eye” in tests for the human response time.
The graph also shows that Typometer has a very good delay measurement accuracy - the lower values are so close to the theoretical 16.68335 that it looks almost like the result of a mathematical calculation.
As for Linux, preference was given to Lubuntu instead of Ubuntu for the same reason - Compiz gives an additional delay in drawing the application. Here is a graph (with median lines):
The effect of Linux Compiz on drawing latency (GVim)
The average delay introduced is approx. 8 ms, which is better than Aero; there is also no discretization caused by synchronization (but there is an increase in jitter). Since V-Sync is not used, video delays are at the level of delays in the frame buffer. It is preferable to use a stack window manager (such as Openbox) to get a higher measurement accuracy.
Given that the measured delays of the fastest applications, such as the Notepad, are below 1 ms and stable, it seems reasonable to assume that the measuring tool provides sufficient accuracy and reproducibility. Since the relationship between the frame buffer and the output video signal is deterministic, the results can be viewed as representative.
Despite the rich variety of observed dependencies, the following typical time series can be distinguished:
Typical editor delay time series
Simple editors exhibit very stable latency values, although the average value may be relatively large.
Complex editors (and editors running on top of a virtual machine / interpreter) in addition to higher average latency often tend to have higher delay variability (jitter).
Intermediate behavior is also common, when intervals of a stable delay value are periodically interrupted by random outliers. Sometimes the delay tends to show a linear dependence on the editor's algorithms for horizontal character positioning.
As an introduction to the delay analysis methodology, I recommend reviewing a large discussion of how not to measure the delay , which explains why average values are better than median as a measure of delay, and why maximum values are very important.
Text file
Let's look at the summary table (sorted by the average value of the delay). RMS here means the standard deviation used as a measure of jitter . Consider that the “ideal” situation is presented here - a simple empty file without highlighting the code. Any other configuration would by definition show higher delays.
Editor delay in Windows (text file):
The final table gives us the opportunity to estimate the distribution of the delay only approximately, therefore it is useful to supplement it with a corresponding more detailed graphic. Traditional histograms are not very convenient for comparing multiple data sets. The span diagrams (“mustache boxes”) are too coarse. The violin charts are better, but they look rather strange for people who are not professionally involved in statistics.
There is a more convenient way, which also looks better - you can graphically plot the values on the horizontal axis with some added random vertical shift to show the distribution (there is additional information about this approach). The resulting diagram is simple and descriptive and allows you to compare different data sets:
Editor delay in Windows (text file)
Obviously, the editors are not created equal (at least, by delay).
First, the average latency varies significantly — simpler editors tend to have lower latency. The winner is GVim, but IDEA with zero delay enabled is very close to GVim. All JVM-based editors (including IDEA in default mode) are at the bottom, which is quite predictable, second only to Atom, since Chrome's work was even more lethargic.
Another noticeable difference is jitter - “light” editors exhibit a very stable delay, while complex ones, on the contrary, have a much wider range of meanings. IDEA in default mode shows the largest delay spread with a high maximum value.
The histogram below shows the detailed impact of the zero delay mode in IntelliJ IDEA:
Effect of Zero Delay on Windows (text file)
The zero delay mode has a positive effect, reducing the average delay and eliminating jitter (but not completely).
Xml file
It is clear that the previous set is too “artificial”; In the end, to edit an empty file without any syntax highlighting, you can simply take Notepad. For something more serious use another editor. Run the input in a relatively large XML file to see how the values change:
Effect of content type on editor latency (Windows)
Wow! The difference is quite noticeable and at the same time unusual. Some editors - GVim and IDEA in zero delay mode - well, simply, “cool guys”, they are “on the drum”. However, with most editors the delay has increased evenly. The average delay in IDEA slightly decreased (which is somewhat strange), but the maximum one increased. The most dramatic change occurred in Emacs, the delay of which simply took off into the sky.
Energy saving
Now disconnect from the mains and we will work from batteries in power saving mode.
Editor delay in Windows (XML file, power saving):
Let's take a closer look at how this has affected the delays:
Impact of power saving mode on editor delay (Windows, XML file)
Most editors did not notice this, but there are a couple of notable exceptions: IDEA and Netbeans. For IDEA, the maximum delay went up to 240 ms, which, quite obviously, is above the “tangible” threshold.
Here it is shown how the zero delay mode affects in these conditions:
Effect of Zero Delay on Windows (XML file, power saving)
And again, although it does not eliminate jitter completely, the impact is significant.
We continue our observations in Linux, skipping for simplicity synthetic test with an empty file.
Linux editor delay (XML file):
Additional Delay Distribution Chart:
Delay Editor in Linux (XML file)
Comparison with previous results in Windows:
Impact of OS on editor latency (XML file)
A common feature is that Linux jitter is noticeably higher for most editors (with the exception of the zero-delay mode in IDEA, where jitter has actually decreased).
Emacs and Atom benefit in Linux - their average latency is noticeably less here.
In GVim, Sublime Text, Eclipse and IDEA (in the default mode), on the contrary, the delay in Linux has increased significantly. The most severe impact experienced IDEA - the maximum delay reached 200 ms even in normal power mode. The reaction time of Eclipse was also hard hit.
Printing in IDEA in the zero-delay mode is, of course, the winner (here IDEA has bypassed even GVim).
Effect of Zero Delay on Linux (XML file)
Linux's zero latency mode demonstrates low and extremely stable latency.
Now suppose, for example, that we use Windows, primarily for games, and work on a Linux virtual machine (really, why not?). How will the editor's delays change in this usage situation? We'll see.
Editor delay in Linux (VirtualBox, XML file):
Here is a comparison with the previous "natural" results:
The effect of virtualization on editor latency (Linux, XML file)
In addition to delay sampling (either caused by vertical sync or another type of discrete buffer synchronization), we can see a constant increase in latency for all editors. Distributions do not change much, which is easily explained (basic algorithms are preserved during visualization). The maximum delay in IDEA increased to 350 ms.
Energy saving
To get the full picture, switch to batteries. The power saving mode together with VirtualBox is probably the most intense combination to delay the editor.
Delay editor in Linux (VirtualBox, XML file, power saving):
Y-yes, such delays are just ridiculous! Maximum delay now exceeds half a second !!!
For clarity, let's compare these data with the results under ideal conditions:
Impact of configuration on editor latency
Clearly, configuration plays an important role in the resulting editor latency. However, the editors react in different ways - the work of some can be seriously degraded, while for others it does not affect much.
The best resistance was demonstrated by IntelliJ IDEA with the zero delay mode enabled. Let's see how it looks in the most difficult situation:
Effect of Zero Delay Mode in VirtualBox (Linux, XML file, power saving)
Interestingly, in the zero delay mode, IntelliJ IDEA surpasses all other editors (and, by the way, console editors too).
Of course, what you type is much more important than how you type. However, visual feedback with low latency can often make this process more efficient and more enjoyable.
• Use a responsive editor.
• Use the keyboard with low latency.
• Turn off all “image enhancers” on your monitor.
• Enable the stack window manager in your OS.
Print with pleasure!
See also:
• Typometer is a tool for measuring and analyzing visual delay in text / code editors.
• The process of drawing with low latency in AWT and Swing - a detailed analysis of the sources of delay in the AWT and Swing architectures, methods for significantly reducing the drawing delay.
More recently, Delay has become a hot topic in the computer world - now there are low-latency keyboards, 144 Hz monitors, special technologies that reduce latency (such as FreeSync or G-Sync ), communities interested in this and so on and so forth. Of course, part of this fashion was created by marketing, but the truth is that a small delay has become possible and desirable.
Obviously, gamers are the first to benefit from such improvements. In some areas, such as virtual reality , latency is a decisive factor, even when it comes to one millisecond. But what about programmers? Do we need to “print with pleasure” in order to “develop with pleasure”? Let's figure it out.
Content:
')
1. Human side
1.1. Feedback
1.2. Motor skill
1.3. Internal model
1.4. Multisensory integration
1.5. Effects
2. Machine side
2.1. Input delay
2.2. Processing delay
2.3. Output delay
2.4. Full delay
3. Comparative tests of editors
3.1. Configuration
3.2. Methodology
3.3. Windows
3.4. Linux
3.5. Virtualbox
4. Conclusions
5. References
1. Human side
The delay in typing is the time interval between pressing a key and the corresponding screen refresh. It sounds simple, but make no mistake: its impact on the keyboard input process is rather complicated, since such typing is an amazing manifestation of coordinated actions of our body and nervous system (at least from a technical point of view).
Let's start with the basics - is it worth it at all to worry about the delay? We do not have any hurry, we can just print what is required, and check the result later. A few seconds does not solve anything, right? Not really.
1.1. Feedback
A person does not “just type” what he wants; we need feedback to fulfill this task, since our feelings form the so-called closed loop control with our movements. A visual image is not only the result of input; It is an integral part of the process.
The more complete feedback we have when working with the keyboard (typing), the better. In principle, you can print with your eyes closed. We can continue typing, even if we plug our ears, relying only on the tactile sensations of the fingers. However, if we block this last feedback channel, then keyboard input will become impossible. Since the visual form of the sensation is dominant (information from other senses usually adapts to the vision) and is the only way to obtain reliable data on input errors, visual feedback is of great importance.
Reducing the delay leads to a “shortening” of the feedback loop, making the input easier, with greater speed and accuracy. So far so good, but where is the reasonable border? In the end, a person reacts incredibly slowly - “the way there and back” from feelings to consciousness and then back to the muscles takes about 200 ms! Undoubtedly, the reaction can be trained, and it is different in people, but some relatively small delay, like, for example, 100 ms, seems to be a good option, isn't it? Not at all.
1.2. Motor skill
Remember your first attempts to use a computer keyboard. Most likely, it took you minutes to press the proper key and then check the result on the screen; this process required all your concentration. However, months and years have flown by, you are now typing amazingly quickly and semi-automatically on the keyboard - you are no longer thinking about any specific keys and, perhaps, don't even look at the keyboard at all ( “blind typing ” ). Practice affects. This process is called “the acquisition of motor skills” (or the acquisition of motor skills ( motor learning )). When the skill reaches the autonomous phase , the task can be performed “automatically” without attracting any attention to its implementation.
Formally speaking, typing (typing on a keyboard) is a process of driving control carried out by a person’s motor system . Since typing (typing on the keyboard) is fine motor skills (coordinated movements of small muscles occur), it is highly dependent on feedback . However, this feedback is processed at the subconscious level, so we will not necessarily be aware of the delay, while experiencing a serious negative impact. The reaction time of a person is important only for correcting errors.
But even semi-automatic processes are limited by visual delay (pdf-file), and any feedback is good only if we can use it. The human vision system takes about 40 ms to process the input. This value also depends on many factors, on a particular person and can be improved by training. We conclude: a delay of less than 20 ms would be acceptable, right? Not really.
1.3. Internal model
First of all, let us clarify that any “external” delay is added to the visual delay, and not superimposed on it, i.e. any delay matters. But one can argue that a value of about 20 ms is still relatively small. Good, but a person’s motor system knows a few dexterity tricks to react faster.
To counteract the input delays in sensory organs and the nervous system, the human movement control system uses a special nervous process known as the internal model . This process can imitate the response (reaction) of the controlled system even before receiving feedback signals - the use of advanced process modeling . Additional inverse model is designed to predict the response (reaction) of the controlled system based on the current feedback.
The delay does not affect the feedback loop directly; it affects, rather, the internal model of the printing process. The direct and inverse models are used in combination with some internal feedback circuits, forming a nonlinear system . As a result, even small delays in feedback signals can lead to significant disruptions when typing on the keyboard (typing).
Separate from the internal model, there is another process that is adversely affected by visual delay — multisensory integration .
1.4. Multisensory integration
The visual image is not the only type of feedback when typing on the keyboard: we can also hear sounds when pressing keys, feel pressure on our fingers, perceive the position of our hands and fingers (so-called proprioception ).
Each of these sensations is processed separately, and the nervous system determines whether or not to use these or other groups of signals. This task is known as the problem of binding and is already a challenge in itself (see, for example, multi-sensory illusions ). When the brain receives exposure from most senses immediately, and the image arrives with some additional delay, this complicates the situation even more.
The nervous system may somewhat adapt (pdf-file) to the constant delay of visual feedback (although not ideal), but any irregularities in the delay time (so-called jitter) create additional problems due to their inherent unpredictability.
There are several illustrative examples from other areas where the delay of the feedback signals can cause worse consequences than its absence, to the point where the initial activity becomes impossible at all: if you play on a MIDI keyboard through a computer, then the delays are 20-30 ms is enough to violate your actions (one article (pdf-file) states that sound delay is important even for 1 ms); another good example is the so-called. SpeechJammer (pdf-file) (“chattering fighter”), which uses a feedback sound delay of approx. 200 ms, temporarily disrupting a person’s ability to speak.
1.5. Effects
Put together the key points:
• Typing (typing on the keyboard) is a complex semi-automatic process that requires years to master.
• In principle, the printing process can be influenced by millisecond delays in visual feedback.
• It is not necessary for consciousness to perceive the presence of a delay, so that, nevertheless, it negatively affects you.
• People vary greatly in susceptibility and tolerance to delay.
But how exactly does the delay affect the typing process (typing on the keyboard)? There are several possible effects:
• Printing slows down.
• The number of errors and their edits increases.
• Eyes get tired more (because the vision system is overloaded).
• Muscles get tired more (as movement control becomes less certain).
• The process requires more informed attention.
The exact effect of the delay depends on many factors, such as the specific distribution of the delay, the hardware used (keyboard, monitor), the content of the editor (text or code), the main activity (insertion / editing), the printing method (regular / blind printing), the specifics your vision and your motor skills, personal preferences, etc.
Needless to say, the possible impact of the delay is hardly pleasant. The good news is that it works in both directions, i.e., by reducing the visual delay, we can, in general, improve many aspects (here we are talking not only about the printing speed itself)
The results obtained are generally consistent with available research data. If there is a desire to get acquainted with this subject more deeply, then one can look at some books and scientific articles containing data on the effect of delay and on the role of visual feedback on the printing process, for example:
• Cognitive aspects of professional typing
• The role of visual feedback from the screen and hands in professional typing (pdf-file)
In particular, it is worth quoting the following ( source ):
Delaying visual feedback on a computer display has an important impact on the operator's behavior and on his job satisfaction.
Let's now look at the side of the car to find out how we can improve the situation with a delay.
2. Machine side
What happens between the moment a key is pressed and the moment a character appears on the screen? It turns out that there are so many different things, and everything takes time. Is it possible to simply buy a top-end computer in order to ensure quiet typing? This will help, but only to some extent, since many parts of this process are independent of the central and / or graphics processor. Take both pills and I will show you how deep the rabbit hole goes (for even what follows is only part of the whole truth).
The delay in printing can be divided into the following components:
• Input delay (keyboard)
• Delay processing (software)
• Output Delay (Monitor)
Consider each component more carefully.
2.1. Input delay
First, let's figure out how a regular non-gaming USB keyboard handles our input. Such keyboards are used most widely now both on desktop computers and on laptops.
Keyboard scan
A regular keyboard contains more than 100 keys, which is quite a lot. To minimize the number of wires and inputs of the control processor , the key switches are usually connected in a matrix circuit , i.e. "Rows" and "columns" of wires intersect. Due to this, the number of wires and inputs can be reduced from “x * y” to “x + y” (for example, from 121 to 22). The consequence of this approach is that the control processor cannot read the state of all keys at the same time - it must periodically scan them with a constant frequency, which leads to some delay. The typical scan rate of the array is 1,000 Hz, so the maximum delay associated with scanning is 1 ms (the average is 0.5 ms).
Contact Bounce
Regardless of the type of keyboard, the key switches are mechanically imperfect and subject to contact bounce — instead of “pure” operation, the switch quickly goes from the “on” state to the “off” state and back several times before it stops. Chatter duration depends on switching technology; for example, for Cherry MX devices, as stated, it is less than 5 ms. Although the exact probability distribution is unknown, but based on the relevant empirical data , it is possible to take a bounce duration of about 1.5 ms.
Eliminate contact bounce
Since the polling frequency is quite high and because of this the bounce can be interpreted as a few keystrokes, the keyboard control processor performs the so-called. eliminating contact bounce , averaging signals over a time interval sufficient to obtain a reliable result. This filtering introduces an additional delay, depending on the firmware of the microcontroller. Since manufacturers, in general, do not report the characteristics of their microprograms, then we consider a typical deblocking algorithm and assume that filtering adds approx. 7 ms delay; so The maximum "time to eliminate bounce" is approx. 12 ms and average approx. 8.5 ms
USB survey
Since USB is a bus controlled by the host computer, the keyboard must wait for a request from that computer to send the registered keystroke data (the keyboard control processor places the collected events in the output buffer). Although USB devices request the required polling rate during initialization (up to 1,000 Hz), operating systems typically use 125 Hz for both low-speed and full-speed (USB1.x) devices; therefore, the maximum delay associated with polling is 8 ms (the average is 4 ms). It should be remembered that often you can increase the frequency of polling manually.
USB conversion
Some time is also required for data conversion. For both low-speed and full-speed devices, the shortest conversion time is 1 ms. In high-speed devices (USB2) this time is much less - approx. 0.001 ms (by the way, there is an excellent article on the suitability of USB for real-time systems (pdf-file)). To minimize data conversion time, it is recommended not to connect broadband USB devices (such as, for example, drives, sound cards, webcams) to the same USB controller / hub to which your keyboard is connected.
So, let's collect the delay values for a typical keyboard:
| A source | Min., Ms | Max. Ms | The average |
|---|---|---|---|
| Matrix scan | 0 | one | 0.5 |
| Eliminate contact bounce | 7 | 12 | 8.5 |
| USB survey | 0 | eight | four |
| USB conversion | one | one | one |
| Total | eight | 22 | four |
These results, in general, correspond to some experimental results on measuring the delay caused by the keyboard.
Is it possible to do better? Of course, easy! Use a professional keyboard:
• switches with a short bounce time (some are even optical )
• high scanning frequency of the matrix
• adaptive debounce algorithm
• customizable firmware
• USB2 for quick polling and low latency conversion
All this can significantly reduce both the maximum and the average value of the keyboard delay. For example, when I purchased the Kinesis Advantage keyboard, I immediately sensed the difference from my previous “regular” keyboard.
Gaming keyboards go even further - if you are a supporter of an uncompromising solution, then you should consider something like Cherry's RealKey technology , in which the key reading goes through analog inputs (and not digital); the delay is almost zero.
2.2. Processing delay
Processing delay is the delay between receiving an input signal from the keyboard and generating an image of the entered character in a video frame. Simply put, this is a delay inside the computer itself.
It should be remembered that the processing delay is not determined only by the performance - theoretically, it is possible to have a system delivering 300 FPS, with a “delay” of 5 seconds after entering. In particular, palletizing and buffering are often an attempt to achieve higher performance due to latency.
While conceptually there are many different sources of processing delay, in practice they are so closely related to the use of an editor that all parts are usually measured together (for experimental data, see the next chapter).
operating system
After the USB host (“USB port” of the computer) receives data from the keyboard, it initiates a hardware interrupt so that the software driver in the operating system can read the received data through the host controller interface (usually via PCI or PCIe ). This data is then processed by the human-machine interface (HID) subsystem in the OS, which ultimately results in placing the key pressed event (of the WM_KEYDOWN type) into the message queue of the operating system. After this, the event is sent by the event loop to the window of the active application.
All these actions require some time, but it is negligible for our purpose (typing on the keyboard). What is important here is that the main operating systems (namely, Windows, Mac, and Linux-based OS) are not real-time systems , so there is no guarantee for the delay value. Both hardware processes (network I / O, storage I / O, etc.) and software multitasking can increase processing time unpredictably (and indefinitely).
By the way, since GUI applications can impose severe restrictions on system latency, there have been many successful attempts to optimize Linux kernel planning specifically for the case of “desktop” use (in particular, through the ulatencyd dynamic optimization system).
For simplicity, suppose that our computer does not have a significant load on keyboard input; then this kind of delay will be less than 1 ms.
Virtual machine
If the text editor / IDE runs on top of the process virtual machine (like the Java JVM or the .NET Framework CLR ), additional delays may occur because their runtime is also not a real-time system (except for special implementations, such as Real time Java ).
Performance by itself does not usually create a problem, but when the JIT compiler or garbage collector is turned on, you can expect some “lag”. JavaScript engines and the Emacs Lisp interpreter also generate this type of delay.
The main virtual machines have improved significantly over many years, however, some preliminary “warm-up” could still be useful to ensure a stable delay.
Editor
This part is the most significant. The editor used can make a major contribution to the delay in typing. Unlike the delays created by the hardware, the maximum delay in the editor is practically unlimited (you can easily stumble upon for 1-2 seconds).
Since the editor is mainly tied to the central processor , it is possible to reduce the delay of the editor using a more powerful machine (it also helps a good graphics processor ). But hope only for power is not entirely justified - it often goes where it is most needed (for example, when you start a development server or process some data in the background). Also keep in mind that even a first-class laptop can be much more sluggish in power saving mode (on battery), so this approach is only partially effective. In addition, it is quite expensive, as you know.
There is a better way - in principle, we don’t need a supercomputer for quiet typing - all we have to do is implement the use of the editor, bearing in mind our goal. Typing in the editor is a relatively simple process, so even computers on a 286 processor provided fairly quick entry. It is quite possible to achieve near-zero printing latency even in a sophisticated modern IDE, which is exactly what zero-delay printing is aimed at in IntelliJ IDEA. For technical details, see my article on low-latency rendering in AWT and Swing (although the Java platform is being considered, key ideas can be extended to most modern operating systems and frameworks for building graphical user interfaces).
Editors / IDEs vary greatly in typing delay. The following chapter contains a large amount of empirical information on the topic.
Rendering pipeline
The central and graphic processor work in parallel and interact through the command buffer , supplemented by the video driver buffer. Most rendering commands are asynchronous. Therefore, they have the full right not to run as soon as the rendering method works. The drawing commands are accumulated in the video driver buffer, then they are packaged and sent to the graphics processor's command buffer (an attempt is made to get a higher frame rate due to the delay). The resulting delay, depending on the combination of hardware / operating system / software interface of the application / video driver, can vary from insignificant to very substantial.
A typical desktop application runs on top of frameworks for building graphical user interfaces, so it is isolated from the underlying rendering pipeline and, thus, from rendering synchronization (rendering). This is usually acceptable, because many desktop applications are not sensitive to latency. However, some actions are extremely sensitive to it (such as typing in an IDE), which is why editors can explicitly “push” commands in the buffer and forcefully render a frame to reduce latency. As an example, see the synchronization job in OpenGL . You can also watch a demonstration material about “pushing through” the conveyor .
Double buffering
In order not to show a partially drawn frame and to present the whole image on the screen at once, many applications turn to the so-called. double buffering - the image is initially prepared in an off-screen “secondary buffer”, and when all graphic operations are completed, the updated image area is transferred to the frame buffer by bit-wise copying or by switching the page . Many frameworks (like Swing ) do double buffering by default.
Needless to say, this extra step leads to an additional delay. The Java documentation says: “If your performance metric is simply the speed at which double buffering or page switching occurs compared to direct rendering, then you may be disappointed. It may turn out that the values of direct rendering will be much higher than those of double buffering, and these, in turn, will be much higher than the page switching. ”
Sometimes double buffering is absolutely necessary; in other cases it is not actually required; therefore, editors should use double buffering cautiously to avoid excessive visual delay. For more information, see the sample buffering costs .
Window manager
Modern applications rarely work in full screen mode; Most desktop environments show each program in a separate window. This task is performed by the so-called. window managers , which can be divided into several classes depending on how the windows are drawn and updated.
, , . ( ), , . : Classic theme Windows, Openbox Linux.
, ( ) . . : Aero Windows, Compiz in Linux.
Relevant empirical data is provided in the next chapter.
Vertical sync
Vertical sync or V-Sync is a method to prevent the image from breaking on the screen , i.e. this state, when the display shows information from several frames in one screen image. The arising distortions are most noticeable on horizontally moving objects with sharp vertical edges (that is, not during printing).
V-Sync ( , V-Sync ). . 17 , — 8 ( 60 ). , , - 4 , ( ). , , 17 .
, V-Sync. V-Sync Windows Aero, Classic theme. V-Sync Linux, , , , .
V-Sync , , - . (. ).
(, / V-Sync):
| A source | ., | ., | , |
|---|---|---|---|
| operating system | 0 | ∞ | ? |
| 0 | ∞ | ? | |
| Editor | 0 | ∞ | ? |
| 0 | ? | ? | |
| 0 | ? | ? | |
| 0 | ? | ? | |
| Vertical sync | 0 | 0 | 0 |
| Total | 0 | ∞ | ? |
These delays are much less predictable than delays caused by hardware, and they are very sensitive to computer configuration. In principle, the total processing delay can be either 0-1 ms, or 10 s. That is why theoretical reflections are not enough here and some exact figures are needed - see the extensive empirical data in the next chapter.
How can I improve the situation with delayed processing? There are several ways:
• Low latency editor / IDE
• Powerful computer hardware (central and graphics processors)
• Stacking window manager (Classic Windows theme, Openbox, etc.).
• Lack of vertical synchronization.
Obviously, the editor is of the greatest importance.
2.3. Output delay
, .
( ). ; , ( VGA, DVI, HDMI, DisplayPort ..), . , , - 60 . , , , 17 , — 8 ( , , ).
- , ( «» — ), - . , , - «» ( , ). ( « »). , . , .. (. Prad , , ). Although in the worst case the delay can be 2-3 frames (i.e. up to 50 ms at a refresh rate of 60 Hz), the input lag is mainly in high definition television and not in computer monitors; therefore, it can be assumed that this delay is close to zero for typical monitors. Nevertheless, it is a good idea to turn off all the “image correctors” on your monitor (oddly enough, and overdrive too ).
Response pixel
Pixels LCD display may not respond to changes in the control voltage immediately. The time interval required to change a pixel on the display is called the pixel response time. . , , - (TN, IPS, VA ..). - , , TN - ( ) 4 .
, :
| A source | ., | , | , |
|---|---|---|---|
| 0 | 17 | eight | |
| 0 | ? | 0 | |
| ? | ? | four | |
| Total | ? | ? | 12 |
? :
• , .
• 144 (, , 3,5 ).
• , Adaptive-Sync , FreeSync G-Sync ( 240 ) .
. 1-2 .
2.4.
:
| A source | , | , |
|---|---|---|
| entrance | 14 | one |
| Treatment | ? | 0 |
| Output | 12 | 2 |
| Total | ? | 3 |
A typical kit consists of a regular non-game keyboard and a standard LCD monitor. The ideal configuration involves a keyboard and monitor (gaming), having a low latency.
The input and output delay components are strictly determined by periodic hardware processes that can be estimated with high accuracy. These delays do not depend on the performance of the central and graphics processors and have predictable upper bounds. The typical average delay of the keyboard and monitor together is about 26 ms, which is not much in itself, but if you add it to the processing delay, the editor delay will be more noticeable. Even the I / O delay in itself already exceeds the threshold of human perception.
/ , , , . ; , . 0-1 .
, , .
3.
, «Typometer» — ( ).
Typometer , . , (.. , , , , ). , , , , , .
3.1. Configuration
Here is the hardware and software configuration used for testing:
Hardware:
• CPU: Intel Core i5 3427U , 1.8 / 2.8 GHz, 3MB cache
• Graphics: Intel HD 4000 (driver v10.18.10.3958)
• Memory : 4 GB DDR3
• Display: 1920 x 1080, 32 bits, 59.94 Hz
Software:
• Microsoft Windows 7 HP x64 SP1 6.1.7601
• Lubuntu Linux 15.10 Desktop amd64
• VirtualBox 5.0.10 on Windows (default settings, full screen mode)
Editors:
• Atom 1.1
• Eclipse 4.5.1
• Emacs 24.5.1
• Gedit 3.10.4
• GVim 7.4.712
• IntelliJ Idea CE 15.0
• Netbeans 8.1
• Sublime Text 3083
, , , . , ( , ); .
, , , . , Notepad () — , .
, . , — Windows , Linux ( Alt+Fn) .
R . ggplot2 .
3.2. Methodology
All editors / IDEs worked with default settings, application windows were maximized.
The editor worked either with an empty text file or with an XML file (more precisely, with a Maven schema ). XML was chosen because it is highlighted in all editors and does not depend on other project files.
Typometer used the following parameters:
• Number of characters: 200
• Delay: 150 ms
• Access: native
• Mode: synchronous
The delay of 150 ms was chosen because it represents the average time interval between keystrokes with my own fairly fast typing (the minimum interval is 40 ms). The exact value does not play a big role, because Typometer in synchronous mode waits for the symbol to appear before pausing and typing the next one.
A classic window manager was used in Windows, because, as mentioned above, compositing implemented in Aero increases rendering delay and forcibly turns on vertical synchronization (tests showed that Aero theme really makes all editors less susceptible). Here is a comparison of GVim tests (one of the fastest editors in general) in the Classic theme and in Aero (dotted lines at 16.68 and 33.37 ms):
The impact of Windows Aero on drawing latency (GVim)
You can see that Aero introduces at least one frame delay (approx. 16.7 ms for a refresh rate of 60 Hz) and leads to time sampling. This hides the internal performance of the editor and distorts the benchmarking process. As I indicated earlier, the video signal delays created by vertical synchronization are slightly less than the delays in the frame buffer, but the average difference is only 4 ms, and the maximum added delay is still 17 ms (for 60 Hz). Since the effect is quite substantial, people often find an added delay “to the naked eye” in tests for the human response time.
The graph also shows that Typometer has a very good delay measurement accuracy - the lower values are so close to the theoretical 16.68335 that it looks almost like the result of a mathematical calculation.
As for Linux, preference was given to Lubuntu instead of Ubuntu for the same reason - Compiz gives an additional delay in drawing the application. Here is a graph (with median lines):
The effect of Linux Compiz on drawing latency (GVim)
The average delay introduced is approx. 8 ms, which is better than Aero; there is also no discretization caused by synchronization (but there is an increase in jitter). Since V-Sync is not used, video delays are at the level of delays in the frame buffer. It is preferable to use a stack window manager (such as Openbox) to get a higher measurement accuracy.
Given that the measured delays of the fastest applications, such as the Notepad, are below 1 ms and stable, it seems reasonable to assume that the measuring tool provides sufficient accuracy and reproducibility. Since the relationship between the frame buffer and the output video signal is deterministic, the results can be viewed as representative.
Despite the rich variety of observed dependencies, the following typical time series can be distinguished:
Typical editor delay time series
Simple editors exhibit very stable latency values, although the average value may be relatively large.
Complex editors (and editors running on top of a virtual machine / interpreter) in addition to higher average latency often tend to have higher delay variability (jitter).
Intermediate behavior is also common, when intervals of a stable delay value are periodically interrupted by random outliers. Sometimes the delay tends to show a linear dependence on the editor's algorithms for horizontal character positioning.
3.3. Windows
As an introduction to the delay analysis methodology, I recommend reviewing a large discussion of how not to measure the delay , which explains why average values are better than median as a measure of delay, and why maximum values are very important.
Text file
Let's look at the summary table (sorted by the average value of the delay). RMS here means the standard deviation used as a measure of jitter . Consider that the “ideal” situation is presented here - a simple empty file without highlighting the code. Any other configuration would by definition show higher delays.
Editor delay in Windows (text file):
| Editor | Min., Ms | Max. Ms | Average, ms | RMS, ms |
|---|---|---|---|---|
| Gvim | 0.2 | 1.2 | 0.9 | 0.2 |
| IDEA (zero delay) | 0.1 | 21.2 | 2.9 | 2.7 |
| Notepad ++ | 0.1 | 5.9 | 4.3 | 0.8 |
| Emacs | 4.2 | 19.2 | 5.3 | 1.1 |
| Sublime text | 6.2 | 35.2 | 8.2 | 2.0 |
| Eclipse | 0.1 | 20.8 | 10.1 | 1.6 |
| Netbeans | 7.3 | 31.6 | 11.8 | 3.9 |
| IDEA | 0.1 | 83.7 | 24.7 | 12.0 |
| Atom | 29.2 | 85,5 | 49.4 | 7.2 |
The final table gives us the opportunity to estimate the distribution of the delay only approximately, therefore it is useful to supplement it with a corresponding more detailed graphic. Traditional histograms are not very convenient for comparing multiple data sets. The span diagrams (“mustache boxes”) are too coarse. The violin charts are better, but they look rather strange for people who are not professionally involved in statistics.
There is a more convenient way, which also looks better - you can graphically plot the values on the horizontal axis with some added random vertical shift to show the distribution (there is additional information about this approach). The resulting diagram is simple and descriptive and allows you to compare different data sets:
Editor delay in Windows (text file)
Obviously, the editors are not created equal (at least, by delay).
First, the average latency varies significantly — simpler editors tend to have lower latency. The winner is GVim, but IDEA with zero delay enabled is very close to GVim. All JVM-based editors (including IDEA in default mode) are at the bottom, which is quite predictable, second only to Atom, since Chrome's work was even more lethargic.
Another noticeable difference is jitter - “light” editors exhibit a very stable delay, while complex ones, on the contrary, have a much wider range of meanings. IDEA in default mode shows the largest delay spread with a high maximum value.
The histogram below shows the detailed impact of the zero delay mode in IntelliJ IDEA:
Effect of Zero Delay on Windows (text file)
The zero delay mode has a positive effect, reducing the average delay and eliminating jitter (but not completely).
Xml file
It is clear that the previous set is too “artificial”; In the end, to edit an empty file without any syntax highlighting, you can simply take Notepad. For something more serious use another editor. Run the input in a relatively large XML file to see how the values change:
Effect of content type on editor latency (Windows)
Wow! The difference is quite noticeable and at the same time unusual. Some editors - GVim and IDEA in zero delay mode - well, simply, “cool guys”, they are “on the drum”. However, with most editors the delay has increased evenly. The average delay in IDEA slightly decreased (which is somewhat strange), but the maximum one increased. The most dramatic change occurred in Emacs, the delay of which simply took off into the sky.
Energy saving
Now disconnect from the mains and we will work from batteries in power saving mode.
Editor delay in Windows (XML file, power saving):
| Editor | Min., Ms | Max. Ms | Average, ms | RMS, ms |
|---|---|---|---|---|
| Gvim | 0.6 | 2.9 | 1.4 | 0.2 |
| IDEA (zero delay) | 1.5 | 58.7 | 4.3 | 7.4 |
| Notepad ++ | 4.8 | 26.1 | 9.8 | 1,3 |
| Sublime text | 10.4 | 19.3 | 12.6 | 0.7 |
| Eclipse | 13.9 | 60.4 | 19.0 | 5.0 |
| IDEA | 13.6 | 239.3 | 45.5 | 39.6 |
| Emacs | 46.1 | 77.4 | 50.5 | 4.3 |
| Netbeans | 11.9 | 138.1 | 59.0 | 21.2 |
| Atom | 48.9 | 104.0 | 60.4 | 7.0 |
Let's take a closer look at how this has affected the delays:
Impact of power saving mode on editor delay (Windows, XML file)
Most editors did not notice this, but there are a couple of notable exceptions: IDEA and Netbeans. For IDEA, the maximum delay went up to 240 ms, which, quite obviously, is above the “tangible” threshold.
Here it is shown how the zero delay mode affects in these conditions:
Effect of Zero Delay on Windows (XML file, power saving)
And again, although it does not eliminate jitter completely, the impact is significant.
3.4. Linux
We continue our observations in Linux, skipping for simplicity synthetic test with an empty file.
Linux editor delay (XML file):
| Editor | Min., Ms | Max. Ms | Average, ms | RMS, ms |
|---|---|---|---|---|
| IDEA (zero delay) | 0.8 | 3.9 | 1.7 | 0.5 |
| Gvim | 1.7 | 8.4 | 4.5 | 1.4 |
| Gedit | 5.0 | 24.2 | 12.4 | 3.0 |
| Emacs | 7.5 | 46.3 | 20.3 | 4.1 |
| Sublime text | 9.4 | 35.4 | 23.1 | 5.2 |
| Netbeans | 8.4 | 92.7 | 24.5 | 12.9 |
| Atom | 16.0 | 59.6 | 32.5 | 8.4 |
| Eclipse | 23.6 | 87.1 | 46.5 | 14.0 |
| IDEA | 10.1 | 198.0 | 69.2 | 27.1 |
Additional Delay Distribution Chart:
Delay Editor in Linux (XML file)
Comparison with previous results in Windows:
Impact of OS on editor latency (XML file)
A common feature is that Linux jitter is noticeably higher for most editors (with the exception of the zero-delay mode in IDEA, where jitter has actually decreased).
Emacs and Atom benefit in Linux - their average latency is noticeably less here.
In GVim, Sublime Text, Eclipse and IDEA (in the default mode), on the contrary, the delay in Linux has increased significantly. The most severe impact experienced IDEA - the maximum delay reached 200 ms even in normal power mode. The reaction time of Eclipse was also hard hit.
Printing in IDEA in the zero-delay mode is, of course, the winner (here IDEA has bypassed even GVim).
Effect of Zero Delay on Linux (XML file)
Linux's zero latency mode demonstrates low and extremely stable latency.
3.5. Virtualbox
Now suppose, for example, that we use Windows, primarily for games, and work on a Linux virtual machine (really, why not?). How will the editor's delays change in this usage situation? We'll see.
Editor delay in Linux (VirtualBox, XML file):
| Editor | Min., Ms | Max. Ms | Average, ms | RMS, ms |
|---|---|---|---|---|
| IDEA (zero delay) | 4.2 | 29.7 | 12.4 | 4.9 |
| Gvim | 6.0 | 26.0 | 18.3 | 4.1 |
| Gedit | 19.5 | 47.6 | 30.1 | 4.8 |
| Emacs | 27.6 | 68.3 | 33.8 | 7.4 |
| Sublime text | 31.5 | 58.2 | 46.1 | 5.2 |
| Netbeans | 12.6 | 159.9 | 46.7 | 19.5 |
| Atom | 29.1 | 89.4 | 62.6 | 10.2 |
| Eclipse | 45.3 | 131.4 | 79.4 | 13.7 |
| IDEA | 29.2 | 347.8 | 87.5 | 42.0 |
Here is a comparison with the previous "natural" results:
The effect of virtualization on editor latency (Linux, XML file)
In addition to delay sampling (either caused by vertical sync or another type of discrete buffer synchronization), we can see a constant increase in latency for all editors. Distributions do not change much, which is easily explained (basic algorithms are preserved during visualization). The maximum delay in IDEA increased to 350 ms.
Energy saving
To get the full picture, switch to batteries. The power saving mode together with VirtualBox is probably the most intense combination to delay the editor.
Delay editor in Linux (VirtualBox, XML file, power saving):
| Editor | Min., Ms | Max. Ms | Average, ms | RMS, ms |
|---|---|---|---|---|
| IDEA (zero delay) | 4.3 | 69,6 | 11.9 | 8.9 |
| Gvim | 5.0 | 35.8 | 19.0 | 3.8 |
| Gedit | 13.4 | 49.3 | 23.9 | 6.0 |
| Emacs | 19.6 | 79.5 | 44.7 | 6.9 |
| Sublime text | 38.1 | 65.0 | 52.1 | 7.3 |
| Atom | 70.2 | 152.2 | 90.0 | 13.7 |
| Netbeans | 35.7 | 344.7 | 119.1 | 43.3 |
| Eclipse | 99.3 | 269.6 | 133.6 | 36.2 |
| IDEA | 119.4 | 544.6 | 198,8 | 63.1 |
Y-yes, such delays are just ridiculous! Maximum delay now exceeds half a second !!!
For clarity, let's compare these data with the results under ideal conditions:
Impact of configuration on editor latency
Clearly, configuration plays an important role in the resulting editor latency. However, the editors react in different ways - the work of some can be seriously degraded, while for others it does not affect much.
The best resistance was demonstrated by IntelliJ IDEA with the zero delay mode enabled. Let's see how it looks in the most difficult situation:
Effect of Zero Delay Mode in VirtualBox (Linux, XML file, power saving)
Interestingly, in the zero delay mode, IntelliJ IDEA surpasses all other editors (and, by the way, console editors too).
4. Conclusions
Of course, what you type is much more important than how you type. However, visual feedback with low latency can often make this process more efficient and more enjoyable.
• Use a responsive editor.
• Use the keyboard with low latency.
• Turn off all “image enhancers” on your monitor.
• Enable the stack window manager in your OS.
Print with pleasure!
5. References
See also:
• Typometer is a tool for measuring and analyzing visual delay in text / code editors.
• The process of drawing with low latency in AWT and Swing - a detailed analysis of the sources of delay in the AWT and Swing architectures, methods for significantly reducing the drawing delay.
Source: https://habr.com/ru/post/305158/
All Articles