Idea logo

The IntelliJ IDEA Blog

The Capable & Ergonomic Java IDE by JetBrains

Early Access Program Features

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 ““to the “” 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!

Comments below can no longer be edited.

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

  1. Charlie Hayes says:

    August 26, 2015

    This is great news!

  2. Tropper says:

    August 26, 2015

    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:

    August 26, 2015

    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:

    August 27, 2015

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

  5. Adam Sandor says:

    August 27, 2015

    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. Andrew Zakordonets says:

    August 27, 2015

    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 requires some specific permissions? I see “User Andrew Zakordonets doesn’t have review access to project idea-community” message and nothing more

    • Andrew Zakordonets says:

      August 27, 2015

      Looks like i found the answer for my first question – either i was not pressing it right at the beginning, or you just need to press Shift first and then Alt + Cmd + / . Anyway, now i see Register window 🙂

      • Andrew Zakordonets says:

        August 27, 2015

        One more suggestion – it would be nice to have a search in Register window – you have a lot of properties there, but no search.

        • Benedikt Stemmildt says:

          August 27, 2015

          You can easily search by just starting to type while having focus in the registry window link in nearly any other intellij window. I was able to type “editor.zer” and it instantly jumpt to the property.

    • Pavel Fatin says:

      August 28, 2015

      The full code is presented as a review in Upsource (may require additional permissions), yet the essential part of the code is also accessible as this commit on GitHub.

  7. Fritz says:

    August 27, 2015

    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:

    August 27, 2015

    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…

    • Pavel Fatin says:

      August 27, 2015

      Hi Aleksey! It’s a known issue (VIM-1007, also related to VIM-970) and we’re going to fix it.

  9. Stu says:

    August 27, 2015

    Can’t wait for this to propagate into pycharm 🙂

  10. Chris Woods says:

    August 28, 2015

    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:

    August 28, 2015

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

    • Pavel Fatin says:

      August 28, 2015

      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:

        January 26, 2016

        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:

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

        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:

          January 27, 2016

          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:

            May 30, 2016

            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:

              May 30, 2016

              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:

                May 31, 2016

                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:

                May 31, 2016

                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:

                May 31, 2016

                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. Baeldung Weekly Review 35 | Baeldung says:

    August 28, 2015

    […] >> Experimental Zero-latency Typing in IntelliJ IDEA 15 EAP [] […]

  13. Jeff says:

    August 28, 2015

    Can someone please confirm when this makes it into PHPStorm?

    • Vladimir Schneider says:

      August 29, 2015

      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. Vladimir Schneider says:

    August 29, 2015

    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. Neue Features für IntelliJ IDEA 15 EAP - says:

    September 1, 2015

    […] sich Pavel Fatin an eine noch experimentelle Implementierung von Zero-Latency-Eingaben in IntelliJ IDEA 15 gewagt, um den Ruf der Java-IDE als „laggy“ zu verbessern. Als Probleme […]

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

    September 3, 2015

    […] by leonegresima [link] [3 comments] Full article:Experimental Zero-latency Typing in IntelliJ IDEA 15 […]

  17. Jason Miller says:

    September 3, 2015

    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:

    September 16, 2015

    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. Norris Shelton says:

    October 2, 2015

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

  20. Chris says:

    October 14, 2015

    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:

    November 5, 2015

    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:

    November 5, 2015

    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:

    December 7, 2015

    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:

      December 7, 2015

      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:

        December 8, 2015

        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:

          December 8, 2015

          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:

            December 9, 2015

            Will try, thanks 🙂

          • Michal says:

            December 21, 2015

            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. Leonardo Constantino says:

    December 26, 2015

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

    • Leonardo Constantino says:

      December 26, 2015

      :.s/ be / /

    • Pavel Fatin says:

      December 26, 2015

      Refinement is still in progress. For a start, we’re considering enabling the feature by default in some recent EAP.

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

    December 26, 2015

    […] is an experimental feature in IDEA products (WebStorm, PHPStorm, PyCharm…) that allows decreasing typing lag. This means […]

  26. George McKinney says:

    February 11, 2016

    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

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

    • Pavel Fatin says:

      February 15, 2016

      Hi George,

      You need to add ““to the “” file to enable the feature.

      • George McKinney says:

        February 18, 2016

        Hmmm. I’ve added that and I still have long pauses. even when IDEA ( build IU-143.1821 ) is the only application I have running on my Kubuntu 14.04 64 bit on a 2 processor AMD64 with 4 GB of memory.

        The project has about 20,000 or so in 30 or so modules of a Maven project.

        Anything I can do other than enhance the hardware?

  27. Karol says:

    March 18, 2016

    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:

    March 18, 2016

    From which version does the ““ work (Idea and Android Studio, please) ?

  29. Grease says:

    April 4, 2016


    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:

    May 3, 2016

    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:

    July 15, 2016

    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:

    August 2, 2016

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

  33. Dmitry Kandalov says:

    September 7, 2016

    Was this feature successful after all or not?

  34. Sergey says:

    November 17, 2016

    Hello Pavel,

    Thank you for this initiative, it really helps a lot on Linux.

    When immediate painting is allowed (e.g. when not inserting chars between existing chars),
    characters appear instantly. I added additional logging, and it takes only 3 milliseconds
    between keyPressed event in EditorImpl KeyListener, and completion of method

    In contrast, when immediate painting is not allowed, it takes some 200-300 milliseconds for the
    character to appear (on a powerful machine with 12-core 2.7HGz processor, 64Gb of RAM, on 4K monitor)

    But overall, editor is still sluggish, especially when actively working on code –
    quickly typing, lots of intellisense popups, autocompletions, etc.

    Is there work in progress on improving the whole editor painting framework?
    You said in the original post that there were plans to redesign it to avoid excessive
    repaints, etc. Is it being done in some branch? What is the branch name?

    I would like to try the latest and greatest code if available, and provide help/testing/feedback
    to you on this important improvement of IDea.

    Thank you,

  35. Barett McGavock says:

    January 5, 2017

    I am seeing 9-10 second lags between typing in my install of IDEA 2016.3.

Discover more