Experimental Zero-latency Typing in IntelliJ IDEA 15 EAP

From what we usually hear, the fans of Vim, Emacs, Sublime and other nice editors often explain their choice by performance concerns. IntelliJ IDEA for example may feel laggy (comparing to a text editor) when you type, and the usual justification for that is some variation of “an intelligent IDE thinks while you’re typing to provide smart coding assistance”. While this is true, should it really be the case? We’ve tried to figure this out.

If you take a look at the implementation of IntelliJ IDEA editor, you’ll spot the problem: every time you change the document, the IDE acquires a read/write lock on it (and interrupt/restart every read operation). However, a more detailed investigation has also shown another source of latency: slow editor repainting.

Instant repainting

Currently, IntelliJ IDEA editor repaints large screen areas far too often (this can be easily verified by adding a trace call to the paintComponent method), and depending on system configuration, such activity may be quite costly.

For example, the editor responsiveness is noticeably lower under X Window System, mainly because of the chatty, a client-server X protocol. Though Wayland can improve that, even in ideal conditions the effect of sub-optimal repainting is very substantial (especially for hi-res displays).

An apparent solution here is to minimize the number of repaint events and their scope. Another important cause of sluggish repainting is our excessive reliance on Swing’s RepaintManager:

  • Repaint events are dispatched via the AWT event queue, obscured by other events (e.g. input, timers, etc.). This can delay the actual repaint. Usually it’s not a problem, yet if we want to achieve instant repaint, it’s better to avoid this.
  • Repainted area is automatically extended to en envelop comprising all invalidated areas. In practice, if we’ve requested repaints of the caret and the status indicator, we may end up with repainting the whole editor.
  • Other components repaints (e.g Project View) may unexpectedly alternate with repaints of the editor, which may also affect the speed of the editor repaint.
  • Double-buffering is always applied (along with BitBLT), yet it may be unnecessary for minor “controllable” repaint events.

The proposed solution is to repaint editor changes instantly, using the underlying Graphics, bypassing RepaintManager (and double-buffering). We can rely on the Graphics.copyArea method working extremely fast to instantaneously shift the line “tail” and the caret. After such a preemptive reaction, an ordinary repaint routine may follow as usual. This way in addition to instantaneous visual response, we can also mitigate the burden of excessive repainting (yet, only to a certain extent of course).

Write/read actions

It’s obviously too wasteful to acquire a lock on the entire project model on every keystroke: this interrupts and restarts any other activity acquired a read lock on the document (think of the amount of unnecessary CPU and thus battery/power usage).

Moreover, such an approach is prone to unpredictable “delay escalation”, when a subsystem or a plugin fails to check the interruption state frequently enough. Those delays could be tolerable, if they weren’t happening on every single keystroke.

What we need is a way to avoid acquiring a write lock during regular and continuous typing (this work is in progress). A simple but efficient workaround is to display input characters before starting the corresponding write action.

Experimental implementation

If you download the latest IntelliJ IDEA 15 EAP build, you can already give a try to the current implementation by adding “editor.zero.latency.typing=true“to the “idea.properties” file.

What’s there:

  • Instant repaint on typing (before a write lock acquisition and main repaint routine);
  • Repaints on other events such as delete, backspace, delete to word start, etc within a single line are performed before the main repaint routine (but after a write lock acquisition).

This should be enough to significantly improve the editor latency. Keep in mind though, that if subsequent blocking or repainting takes more time than a period until the next key is pressed, a typing lag is still possible.

The implementation is by no means complete, and minor glitches are expected. For us it’s just a proof of concept to build upon. Meanwhile we’re going to implement a generalized way to avoid write actions during continuous typing. We also consider employing the proposed technique for caret movement.

Measuring visual delays

When improving something, it’s always worth to measure it. To do that correctly, we need to encompass the entire repainting cycle which goes beyond JVM (e.g, in X system Graphics content is separated from the actual framebuffer). I’ve tried to create some kind of “type-o-meter” using AWT Robot for that purpose, yet it seems a more low-level tool is needed to achieve acceptable accuracy.

An objective comparison of the improved editor responsiveness to other IDEs and editors potentially can persuade reluctant users to finally adopt IntelliJ-based products (and finally bring “typing with pleasure” for all the rest).

Remember that we count on your feedback a lot for improving the current implementation. That’s why you’re very welcome to share your impression and thoughts with us in our EAP discussion forum and issue tracker.

Develop with Pleasure!

About Pavel Fatin

Programming enthusiast, technology advocate. IntelliJ Scala plugin developer at JetBrains, https://pavelfatin.com
This entry was posted in EAP Releases, New Features and tagged , , , . Bookmark the permalink.

57 Responses to Experimental Zero-latency Typing in IntelliJ IDEA 15 EAP

  1. Charlie Hayes says:

    This is great news!

  2. Tropper says:

    Can’t wait to test this for my self.

    I always find it a bit annoying that the IDE feels a bit laggy – but indeed I always thought: well it’s a smart IDE, so it needs time to think. :-)

  3. Fritz says:

    This is great news. The lag is the reason why I usually just keep going back to Sublime.
    I absolutely detest laggy IDEs, even if they are as good as yours.

  4. Sibusiso says:

    Aha.. I have always wondered why my battery deoleted so quickly while working on Android Studio

  5. Adam Sandor says:

    I’m very interested to see the effect these improvements, but I don’t see the largest smartide tax during editing. Indexing of the project is a much worse problem in my opinion. Every time I have to switch branches or do a git pull I cringe at how much time it will take until the IDE becomes usable again. Same with changes to my pom files. Of course this is no easy problem to solve either, but for me those are the moments when I wish my IDE wouldn’t be so smart.

  6. Sounds awesome ! 2 questions :
    1. To enable it on a mac i need to press Cmd + Alt + Shift + / , but IDEA doesn’t show anyhow that this feature is enabled or disabled. Is there any other way to check it’s status?
    2. Your link to youtrack https://upsource.jetbrains.com/idea-community/review/IDEA-COMMUNITY-CR-2338 requires some specific permissions? I see “User Andrew Zakordonets doesn’t have review access to project idea-community” message and nothing more

  7. Fritz says:

    I’ve played around with it now for a bit, both on Windows 10 and on Ubuntu 14.04.
    All I can say is that I’M LOVING IT!

  8. Aleksey Zhidkov says:

    Right now it’s not works smoothly with IdeaVim (in normal mode characters are appearing for a moment). Are you planning to make zero latency typing and IdeaVim to work smooth together? For me seems like it’s not possible by design…

  9. Stu says:

    Can’t wait for this to propagate into pycharm :)

  10. Chris Woods says:

    The improvement on Linux is quite dramatic. I’m forced to use eclipse for my day job, but they seem to be taking seriously the opinions of the ~500 developers who have to work with it every day. This could be a big help in promoting IDEA at work.

  11. Mike Hedman says:

    This sounds great! Will this functionality also be in the PhpStorm EAP builds?

    • Pavel Fatin says:

      Eventually, the code will be propagated to all IDEA-based products (including PhpStrom, PyCharm, RubyMine, WebStorm, AppCode, CLion, etc.).

      There’s a chance that some version of the functionality is already included in a specific application.

      By the way, those who cannot access the implementation code in Upsource, may take a look at the initial commit on GitHub.

      • Mat Gessel says:

        Does not appear to do anything in PyCharm 5.0.3.

        I found a partial workaround though. I have a 2560 x 1440 monitor and like to use the entire screen for my IDE. I typically have 2 or 3 editor panes open. I was finding typing latency to be very high; like using SSH over a poor connection. The workaround is to split my PyCharm workspace into 3 separate windows:
        https://www.jetbrains.com/idea/help/detaching-editor-tabs.html

        On Mac OS you can monitor screen repaints using the Quartz Debug tool. You can download it here (free, but requires Apple ID):
        https://developer.apple.com/Downloads

        In PyCharm, each character I type triggers a handful of full-window updates (tip: disable cursor blinking while testing). It’s much slower with multiple editors. Compare with Eclipse, where each character triggers a small rect update in the editor, followed by small rect updates in rest of the IDE after idle for a moment.

        • Pavel Fatin says:

          Hi Mat, thanks for the info!

          Experimental data confirms that zero-latency mode can reduce typing latency significantly (and PyCharm should not be an exception).

          You may use Typometer to measure the delays objectively, instead of relying on the indirect methods, i.e. monitoring re-painting (more info on painting latency in AWT / Swing).

          • Fenn says:

            Hi Pavel,

            I’m seeing the same behaviour as Mat using the Quartz debug to observe screen draws on Pycharm 2016.1.4 on OSX.

            Even with zero-latency mode turned on, every character causes a full window repaint.

            Not just that, but even if the mouse/keyboard is not being touched at all, the window does full repaints constantly, even though there’s nothing to update.

            If I turn on “show identical screen updates” (eg: draws that change nothing), it’s constantly redrawing the screen with no changes.

            Any ideas what could be happening here? It feels like this could be one of the major causes of latency/speed issues on OSX.

            • Pavel Fatin says:

              Zero-latency mode reduces visual delay by performing fast, partial screen updates before those full-screen repaints. So, while Quartz debug detects the full-screen repainting, the typing latency should be reduced.

              You can use Typometer to measure the latency. Here are latency numbers in Windows and Linux. As I personally don’t use Mac, there’s no Mac OS-related data in the article, however, I’ve run a quick benchmark of zero-latency mode in IDEA on 13-inch MacBook Pro (Retina), in a Scala file: average latency ~90 ms -> ~20 ms, minimum latency ~60 ms -> ~3 ms.

              I explained why latency of AWT / Swing painting routine is suboptimal in an article “Low-latency painting in AWT and Swing”. Feel free to check it for more technical details and code examples.

              • Fenn says:

                Hi Pavel, thanks for the fast response. I’d already tried to run Typometer, but was having trouble with it being unable to detect the reference pattern.

                I ended up getting it working by increasing the delay and using async.

                Here’s the results for Pycharm on a latest generation Macbook Pro i7 13″ retina, with zero-latency turned on:
                – Min: 20.1ms
                – Max: 116.1ms
                – Avg: 33.3ms

                This makes it the slowest observed editor in any of the benchmarks :)

                Any ideas as to how I might to about debugging this?

                • Fenn says:

                  Sorry, I was mixing up the columns – _not_ the slowest, but still notably slower than the 4.3ms you observed in zero-latency mode in IDEA.

                  • Pavel Fatin says:

                    Hi Fenn!

                    Those measurements were acquired in the specific hardware / software setup, which I precisely described. Because there are many, many factors that can influence the result, we cannot simply extrapolate the numbers to some arbitrary configuration.

                    With regard to your data, 1000 / 60 * 2 = 33,(3), which means that your OS enforces V-Sync (might depend on OS X version). As I pointed out in the article, V-Sync conceals intrinsic editor performance and disrupts the benchmarking process.

                    Please note that how we think about V-Sync in a text / code editor significantly differs from such a reasoning for a video game:
                    * updates are not generated at a constant rate,
                    * keystroke times are fundamentally unpredictable,
                    * text line occupies only ~1/50 of the frame.

                    As far as I know, there are some tweaks to disable V-Sync in OS X (with reports of increased system performance / responsiveness), though it’s hard to say how they work internally.

  12. Pingback: Baeldung Weekly Review 35 | Baeldung

  13. Jeff says:

    Can someone please confirm when this makes it into PHPStorm?

    • It is in the PhpStorm EAP. Just downloaded it. Tried it. Sweet!

      I love typing again. I always hated lag during typing. IntelliJ just made be more tolerant because of all the comforts but now it is almost perfect. Brains and speed, all in one package.

      I love it.

  14. More than sweet. PhpStorm EAP seems to come up at least twice as fast. Did not time it but compared to the release version the project flashes onto the screen. I used to open the IDE in the morning and not shut it down until I was done for the day because it was slow to come up.

    Not anymore. Awesome job on this one. I love it.

  15. Pingback: Neue Features für IntelliJ IDEA 15 EAP - jaxenter.de

  16. Pingback: Experimental Zero-latency Typing in IntelliJ IDEA 15 EAP | JAVA

  17. Jason Miller says:

    So I just tried this out. The latency improvement is pretty significant when using the IntelliJ vim plugin, as before I had a lot of problems with the latency causing keys to fire into the wrong modes. It feels substantially smoother now, much more so than I would have expected.

    It does cause an interesting visual quirk though – command bindings (e.g. normal mode) now sometimes show up as text input for a split second before being intercepted by the vim plugin. Not a big deal, and more than worth it to get the huge reduction in latency.

  18. Michal Skrzedziejewski says:

    Amazing, this really improves typing latency, especially in conjunction with IdeaVIM. And for now I can live with this oddity of VIM commands appearing momentarily in the editor :)

  19. Awesome. I can’t wait to take it for a spin.

  20. Chris says:

    Did this feature make it into the recently released preview? Zero-latency typing is one of the main reasons I’m excited about IntelliJ 15, so I’m really hoping it will make it to release

  21. Andy Edwards says:

    Are those really the only potential causes? For the past hour on my comp, WebStorm (the entire program) freezes about every 10 seconds, each freeze lasting a second or two. I would think a lock on the text editor can’t be involved with whole-app freezes. Usually the wait cursor shows up halfway through the freeze, so I get the impression that my non-SSD hard disk must be involved. Maybe the amount of memory involved in background work causes a lot of paging?

  22. Andy Edwards says:

    And, ironically, WebStorm has Sublime Text 3 completely beat on jumping to files. In my experience, the more files I have in my Sublime Text 3 workspace, the longer it freezes when I use Go To Anything. It’s practically unusuable on this comp at least.

  23. Michal says:

    Any chance this is backported to Idea 14?
    If not, if I apply this patch to Idea 14 sources does it have any chance of working?

    • Pavel Fatin says:

      The feature is still experimental. We might backport it when it will be stabilized.

      It’s perfectly possible to backport the functionality manually – simply cherry-pick all the “Zero-latency typing*” commits.

      In principle, zero-latency mode should work just fine in IDEA 14.

      • Michal says:

        Thanks for the info Pavel. About cherry picking, might be a bit more involved, because it seems some classes are missing in 14.x.

        I am wondering though, assuming I back port it correctly and my Idea 14 community builds, how do I apply this to ultimate? Is it enough to replace some JARs?

        • Pavel Fatin says:

          I recommend you to use Git to “squash” all those commits into a single one, which will result in a quite clean and isolated code. Convert this commit to a patch (via Git), and apply the patch to IDEA 14 code.

          You will clearly see which classes are affected, so you should be able to select and transfer those classes to IDEA Ultimate jar (using an archiver or a file manager), just make sure that IDEA build versions match.

          • Michal says:

            Will try, thanks :)

          • Michal says:

            I managed to cherry-pick your commit and squash it into one patch, and correct it so that it applies cleanly (as far as code text goes) to idea 14.

            However, seems that there were too many breaking changes in the editor code between 14 and 15 for the patch to work and without knowing the internals it’s too difficult for me to correct, so I gave up.

            Let me know if those patches are of any use to you.

  24. Very exciting news! When should we be expect to see this update on RubyMine?

  25. Pingback: Decrease typing lag in WebStorm (or any IDEA product) | alex bumbu

  26. George McKinney says:

    Just came across this post. It seems to address an annoyance I have.

    I’m using 15.0.2 ( IU-143.1184.17 ) and don’t see the property in idea.properties

    Is it now baked in, or should I give it a try?
    Thanks

  27. Karol says:

    I think this should be the topmost priority.
    Very, very often (most of the time?) I can barely type or even move the cursor in Android Studio. I think this could be called a crisis.
    With only 2 small Android projects loaded (+ Kotlin if that could be affecting).
    And, believe it or not, typing text is sometimes important in an IDE ;-).
    No wonder many people go “luddite” with Vim instead of IDE.
    Macbook Pro, 16GiB RAM, SSD, etc. So I don’t think my system is the problem.
    Please, please MAKE TEXT EDITING WORK (and the UI in general) without choking every 2 seconds. The UI should be more independent from background tasks and not get blocked by them!
    Any release date on the horizon?
    Has this been released in ideaIC-2016.1 ?

  28. Karol says:

    From which version does the “editor.zero.latency.typing=true“ work (Idea and Android Studio, please) ?

  29. Grease says:

    THIS IS GREAT.

    I’ve been typing for a long time, getting delayed by waiting for Intellisense to come to it’s .. ‘senses’ . he. he.

    totally resolved. you guys are my heroes.

  30. Hans says:

    Wow, I had such crazy latency issues on my retina iMac, I could not even work with our raging anymore. This was the only solution to it!! Any idea when this will be standard? Hopefully soon!

  31. J says:

    So glad I found this– using with RubyMine. I just hope there aren’t any nasty bugs since the issue seems to have gone quiet and it wasn’t made standard.

  32. Peter Ehrlich says:

    Holy @#$! This is wonderful. Why is it not the default? I almost ditched RubyMine over this.

  33. Dmitry Kandalov says:

    Was this feature successful after all or not?

Leave a Reply

Your email address will not be published. Required fields are marked *