from Hacker News

VS Code uses 13% CPU when idle due to blinking cursor rendering

by Kristine1975 on 3/23/17, 2:29 PM with 760 comments

• by artursapek on 3/23/17, 3:17 PM

  I'm reminded of this classic: https://github.com/npm/npm/issues/11283

  NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious.

  My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't apply to VS Code's cursor.

• by Philipp__ on 3/23/17, 3:11 PM

  It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS?

  Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated.

  Edit: Many people here think that I am attacking this web based kind of technology, which I am not, and sorry for not being clear enough, but why chose something so high up the stack for dev tool?

  Edit2: For non-believers in nested comments, look -> https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

• by aphextron on 3/23/17, 3:14 PM

  I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE.

  Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

  Note that Atom and VSCode are nearly 10x slower than all the other competition, as well as simply crashing for many of the tests. To be fair, I do think Electron based desktop apps have their niche. Spotify is a perfect example. But they have no place in text editing.

• by ChuckMcM on 3/23/17, 3:36 PM

  I love the irony of simulating an XOR gate from a piece of hardware (a serial terminal) with a billion gates in a processor which renders a square with an alpha blend function. Sort of like using a 787 to sit on the runway, and run its engines to blow a windmill to crank a butter churn :-).

• by camgunz on 3/24/17, 8:07 AM

  The answer to all this is: "use Qt".

  "But camgunz, I only know JavaScript"

  That's cool! Look into QML.

  "But camgunz, I only know X"

  That's cool too! Qt4 has a truly ludicrous number of language bindings: https://en.wikipedia.org/wiki/List_of_language_bindings_for_.... Qt5 has a fair number too: https://wiki.qt.io/Language_Bindings.

  "But camgunz, I need an embedded browser"

  I agree, separate windows are for savages. Qt has you covered with Qt WebBrowser.

  "I need a native look and feel across all platforms"

  Well, that's a pipe dream. BUT, you can get closer with Qt than anything else. Google for some screenshots.

  "I need a bananas style but I don't want to write any code"

  Qt supports CSS-like stylesheets!

  ---

  The web isn't a good application platform. Sure we could (and have been) spend billions of engineering hours and years to get it up to speed with exactly what we have now, but that's obviously a bad idea. We can figure out zero-install and sandboxing, but we just don't need to shoehorn everything into JS, weird APIs like localstorage and webrtc, and the DOM. We just don't need to.

• by okket on 3/23/17, 3:01 PM

  TL;DR: It seems to be a problem in Chromium, the relevant CSS (one second change) results in a 60hz animation cycle.

  Workaround:

    "editor.cursorBlinking": "solid"

• by mmarks on 3/23/17, 3:31 PM

  13% cpu usage at the lowest c-state is a also very different than 13% at an elevated c-states. I've recently spent a lot of time analyzing c-states/p-states and the power mgmt modes of the GPU. After learning more about the complexity behind the clocks, bus speeds, etc. underlying each state, whenever I hear someone quote a utilization number of a minor workload, I want to know at what power state.

  Not to take away but the author's point, just an aside that utilization numbers can be a lot more complicated when there are dozens of energy states and the utilization might be utilization at a particular state rather than utilization at maximum power

• by tomc1985 on 3/23/17, 3:48 PM

  The amount of bad hacking that has to happen for NodeJS to work as a platform has said all I could ever want to possibly know about the quality of NodeJS developers: so pathetically in love with their trainwreck of a language that they would rather pile kludge upon hack upon kludge than to learn the language and environment most appropriate and most computationally efficient for the tasks at hand. Javascript devs would rather just throw JS at it

• by mschaef on 3/23/17, 3:09 PM

  This reminds me that as part of the Windows95 development effort, Microsoft disabled per-second updates of the taskbar clock to improve performance. Raymond Chen wrote a bit on it back in 2003:

  https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=...

• by adamnemecek on 3/23/17, 3:04 PM

  ...21st century desktop application development ladies and gentlemen (not that I'm proposing anything constructive).

• by c-smile on 3/23/17, 5:32 PM

  In GDI era caret bar ( that's not cursor, sic!) was rendered as by simply inverting pixels (InvertRect() call) inplace in video frame buffer. Very cheap operation that does not require redrawing and run of any other code.

  With the GPU the only viable option for rendering blinking caret is to redraw the whole window. That's why it takes so much CPU as Chrome uses mostly CPU based rasterizer.

  But redrawing the whole window in GPU is not that bad if the renderer is capable of caching GPU objects while rendering.

  Here is what happens in Sciter (https://sciter.com) while rendering blinking caret in screen of similar complexity (editor with syntax hihglighting):

  https://sciter.com/images/sciter-caret-cpu-consumption.png

  As you see it CPU consumption is near to zero.

• by Mahn on 3/23/17, 3:05 PM

  Sounds like this can be fixed by moving away from animating opacity to something more rudimentary like flipping the display property in JS. CSS3 animations from my experience are a bit taxing in general, and something you want to use only in small bursts, not constantly running in the background.

• by eranation on 3/23/17, 6:29 PM

  This is where Bert Bos (Created jokingly the notorious, unofficial, abused blink tag https://www.w3.org/Style/HTML40-plus-blink.dtd) should have a little "told you someone will need it someday" moment ;)

• by Skywing on 3/23/17, 3:59 PM

  Ah yes. The classic text editor debate thread. In this thread you can expect to find folks claiming that 2 seconds of startup time for editors, like Atom, is so disruptive to their workflow that they'd rather use notepad.

• by kibwen on 3/23/17, 6:02 PM

  Not to defend Electron (I use neither VSCode nor Atom), but meanwhile I'm over here watching the JVM consume a constant 10% of my CPU thanks to having a single 60-line file open in the official Arduino editor (which isn't even an IDE, it's a glorified GUI for compiler flags with a built-in syntax highlighter).

• by ohitsdom on 3/23/17, 3:44 PM

  The Chromium bug describes the root cause, which is a fixed schedule interval for CSS animations:

  > The JS implementation uses an interval of 500ms between updates while native animations will be updating at 60Hz. At the moment we're not smart enough to deschedule ourselves during animations with step timing functions.

  https://bugs.chromium.org/p/chromium/issues/detail?id=500259

• by logicallee on 3/23/17, 5:17 PM

  You know how there's like, hard real time embedded programming where if you don't hit your realtime deadline every time without exception forever, your engine explodes or something?

  Well, apparently the web is built on whatever the opposite of that style of programming is.

• by davidascher on 3/23/17, 3:04 PM

  Reminds me of this ancient Firefox bug about the performance cost of the throbber: https://bugzilla.mozilla.org/show_bug.cgi?id=437829

• by agumonkey on 3/23/17, 8:20 PM

  I hope y'all never have the chance to boot Turbo Pascal 7.0 (DOS) on a P5 class cpu. It's pretty sad. I mean a 700KB IDE with decent language to native code with some form of live check, instantaneous compilation times, modular programming, online help; multiple windows and a cult classic color scheme. It hurts.

• by makecheck on 3/23/17, 3:56 PM

  Developers often work on extremely fast machines for their own productivity/sanity but this is a reminder that it can help to test on a slower setup from time to time. Or more generally, test edge cases.

  For instance, if you have a graphics tool that briefly flashes screen updates, the problems are much easier to see. On a fast system, you might not only miss an unnecessary refresh of “everything”, you may miss a repeated refresh of the same content.

  Also, on slower systems, the cost to generate a frame may delay an entire sequence. Consider something like “live resizing”: on your spiffy machine it seems fluid, on a lesser machine it might be stuttering like crazy. Sometimes you have to cheapen the computations occurring during rendering to make sure it’s OK.

• by abrkn on 3/23/17, 3:06 PM

  I recently switched from Atom to VS Code and have noticed a considerable reduction in lag, especially when using CMD+D and searching through project files.

• by Animats on 3/23/17, 6:24 PM

  I had something like this happen with QNX, back in 2004 when we were using it for the DARPA Grand Challenge. We had an industrial x86 computer system that was running headless, with no display. But the device had a minimal VGA controller on the motherboard. So QNX brought up a screen saver on the slow VGA controller, where reading from display memory was very slow. The screen saver was reading from display memory to move the screen saver box around. This used up about 15% of the CPU.

  The QNX people were really embarrassed about that and fixed the screen saver. We just reconfigured to turn off the display entirely.

• by jankotek on 3/23/17, 6:03 PM

  It is easy to do screen redrawing wrong. Intellij Idea had similar problem:

  https://blog.jetbrains.com/idea/2015/08/experimental-zero-la...

• by bitwize on 3/23/17, 7:34 PM

  An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible GUI implementation, and they can't live without the crutches VSCode provides when shitting out Go microservices.

  Many of these same people will argue vehemently that X11, the shitty GUI layer for Linux that ran perfectly fine 20 years ago, is "slow" and "bloated" and needs to be replaced with Wayland, a new, completely different, shitty GUI layer.

• by jokoon on 3/24/17, 12:23 PM

  This comment section deserve to be posted in some kind of drama-oriented section, a little like /r/subredditdrama

  Personally I'm waiting for the second net bubble to burst, so that we can force everyone to use a stricter markup language.

  Everyone is seeing how android apps are slowly but literally making HTML completely obsolete, and honestly that's an awesome thing, because it's really needed.

  I hope the tech market realizes that and evolve quickly, instead of waiting for some battery breakthrough.

  Never forget about the Andy Bernhardt video about the birth and death of javascript.

  Those issues are why I will always target C++/java jobs and laugh at anything related to the "web". I am never short of the amount of analogies I can invent about HTML/JS. It's like comparing stick and stones to a decent steam engine.

• by tete on 3/23/17, 5:30 PM

  This is when I think that the following two minute video should be mandatory for programmers:

  (Grace Hopper - Nanoseconds) https://www.youtube.com/watch?v=JEpsKnWZrJ8

• by k__ on 3/23/17, 4:20 PM

  I don't understand all the hate.

  Java developers have intelliJ IDEA, Eclipse and Netbeans, all written in Java.

  JavaScript developers have Atom and VSCode. Since JS was created for HTML, it seems logical for me to use browser tech to build these editors.

  It allows JS devs to build extensions without the need to learn a different language. As Java devs can build Eclipse plugins with Java.

  Also, the Electron based editors aren't the only ones available, so it isn't as if someone would force the poor dumb JS developers to use these clunky slow tools, like when Slack built their client with Electron and you had to run a monster app for a simple chat.

  If they want something faster, there is Sublime, Vim and Emacs...

• by angrygoat on 3/23/17, 4:16 PM

  From 2009 – Much hot air over blinking cursors https://lwn.net/Articles/317922/

  Quote from the article;

  > The blinking cursor causes the processor and GPU to be woken up frequently. On one of my test systems, this causes somewhere in the region of 2 Watts of extra power consumption.

  This isn't about electron vs "native" apps. It's just that a smooth cursor animation rendered at 60Hz costs power; and if you look at the github issue, one config setting and that's gone, and so is the power usage when idle.

• by qeternity on 3/23/17, 4:35 PM

  Just another day in the Electron universe. My personal favorite is resource waste of another variety: Slack and WhatsApp using multiple gigs of RAM for unbelievable basic (which is their selling point) chat apps.

• by corford on 3/23/17, 10:32 PM

  Hilarious. I can reproduce on my Dell Inspiron 15 5000 (core i7 running Windows 10) but it's not as pronounced as in the bug report. CPU usage bounces between 0.5% and 2.5% (which is obviously still ridiculous).

  I almost want to swap back to using sublime out of protest but vscode's tighter git integration/workflow is hard to give up :(

  Edit: I've always wondered why vscode couldn't be written in portable C/C++/Rust/D and then embed a V8 engine to power a javascript plugin API (a bit like sublime does with python)?

• by saghm on 3/23/17, 7:28 PM

  I always turn off cursor blinking everywhere I can because I find it distracting; I never knew I could use "performance" as an excuse!

  On another note, why is cursor blinking such a universal thing? I assume that other people must like it, or else it wouldn't be so common. Do people have trouble finding their cursor without it, or do they have trouble distinguishing it from actual text? I've never had either of those problems with blinking turned off, but I can't think of any other plausible reason.

• by DonHopkins on 3/23/17, 4:24 PM

  Rik Arends, who worked on the Cloud9 IDE, has done some amazing work implementing a blazingly fast WebGL based code editor and text formatting and rendering with JavaScript and GPU shaders. He's actually compiling JavaScript code into WebGL shaders!

  Implementing a WebGL based code editor for JavaScript - Rik Arends - GrunnJS [1]

  How do you render text and update a code editor when it only has vertexbuffers? What can you do with it? What does an AST editor do to help? Rik Arends (founder of Ajax.org/Cloud9) will blow your mind with the talk. Note that this editor is work in progress.

  [1] https://www.youtube.com/watch?v=hM1oLr9G3-Q

  Here are some other talks about his work:

  Rik Arends: Multi-threaded JavaScript inside Makepad [2]

  As a web developer since the early 2000s, Rik has lived through the ups and downs of browsers all the way from IE3 to Chrome 52. From doing interactive web projects for big brands to working on Cloud9 IDE, the limitations of HTML have always been there. After leaving Cloud9 four years ago to explore the new possibilities that WebGL offers for UI, a continuous stream of WebGL-related projects have appeared, including a JavaScript trace debugger, a compile-to-JavaScript language and a live coding prototyping framework. Makepad is the latest from-scratch iteration of this WebGL direction, and it is exciting to share the progress and lessons learned.

  [2] https://www.youtube.com/watch?v=tVTWdFE6-O0

  Rik Arends: Beyond HTML and CSS: Fusing Javascript and shaders | JSConf EU 2014

  What would the world look like when you can style UI with actual shader programs? The web could be 60fps on mobile, and we can start to imagine what lies beyond HTML and CSS

  [3] https://www.youtube.com/watch?v=X8xxz-YeWtk

  Here's a demo! [4]

  [4] https://makepad.github.io/makepad.html

• by pointernil on 3/23/17, 6:46 PM

  Thinking about "the stack", runtimes , development processes and the root-causes involved here i think, the best thing that could happen to "the industry" is some event preventing the silicon production to deliver new cpu-s/ram/gpu-s/harddrives for some 5+ years or so.

  Constrain the resources to bring brack some sane levels of efficiency regarding ram/cpu-cycles/hd-space.

  /scnr

• by roryisok on 3/23/17, 8:32 PM

  I just checked on Windows 10, an empty instance of VS Code with a blinking cursor uses 0% most of the time.

  Is this a MacOS only issue? Does it affect Atom?

• by coding123 on 3/23/17, 6:34 PM

  Thank you to the author of this github issue! I hope it gets sorted soon! I use VSCode a lot when disconnected from my power outlet.

• by kelvin0 on 3/23/17, 6:37 PM

  Simple fix: ... cursor.blink = False // 13% CPU optimization :-) ...

• by rbanffy on 3/23/17, 4:12 PM

  We could call it Egacs: "Eight Gigabytes And Constantly Swapping"...

• by kardashev on 3/23/17, 4:38 PM

  I think the reason using the browser for desktop UI is because graphics and UI programming is terrible. The computer architecture and operating systems we use today are built on tech that was before graphics existed.

  That's why it's trivial to build a terminal app, but god help you if you want to create a window with a button or draw a line. GLEW, GLUT, Qt, OpenGL, and the rest are just kludges to deal with the fact that we're still working with tech from the 70's. Even those kludges are so terrible that companies like Github and Microsoft have resorted to using the browser to make things like Atom and Visual Studio Code.

  It can be fixed, but I'm not sure anyone has the fortitude to redesign hardware and operating systems.

• by ericfrederich on 3/23/17, 5:20 PM

  Dude... that cursor has a carbon footprint.

  I hope when Microsoft fixes this they publish some usage stats and we can see how much energy/money/carbon this will save annually.

• by scriptproof on 3/24/17, 7:43 AM

  It is amazing this article got more than 700 points because when I open the task manager and VSC is in IDLE, I see 0% in CPU usage. And the cursor is blinking!!!

• by caseymarquis on 3/23/17, 6:48 PM

  Crossing my fingers any related changes don't kill the cursor in the vim extension. Maybe I'll skip the next few updates...

• by joe563323 on 3/24/17, 9:09 AM

  On a not so different not xfce had a bug when the screen saver got displayed after idle timeout the cpu utiliztation rose over 100%.

• by GoToRO on 3/23/17, 4:32 PM

  I noticed that somethimes when you press TAB at the beginning of a line, it can take about 1s for the TAB to appear on the screen.

• by CodeWriter23 on 3/23/17, 5:06 PM

  Why hasn't someone thought of implementing a blinking cursor in hardware, like we did in the early 80's?

• by batmansmk on 3/23/17, 4:10 PM

  This bug has nothing to do with techonology choices. It is just a bug, in chromium. Team is investigating.

• by Ace17 on 3/24/17, 5:33 AM

  No issue, just need a plugin to disable cursor rendering when you launch the build :-)

• by nebabyte on 3/24/17, 12:56 PM

  > Powerful* text editors built on the web stack

  I've identified the problem

• by hesarenu on 3/24/17, 10:23 AM

  Could not Electron use React Native kind of framework?

• by z3t4 on 3/24/17, 9:55 AM

  You do not need horses to power your computer.

• by plg on 3/23/17, 3:10 PM

  carbon footprint

• by excalibur on 3/23/17, 3:42 PM

  Lotus Notes FTW

• by am185 on 3/24/17, 1:53 AM

  can you close VS Code when not in use?

• by knodi on 3/23/17, 6:08 PM

  The power of node.js -_-

• by SippinLean on 3/23/17, 4:50 PM

  I wonder if adding

    will-change: opacity
  

  to the CSS would improve performance (by switching CSS animation rendering to the GPU)

  https://medium.com/outsystems-experts/how-to-achieve-60-fps-...

• by yAnonymous on 3/24/17, 9:44 AM

  Why don't all those who complain about Electron apps get together and make a FOSS, cross-platform editor with all the features and an equal or better interface than VS Code and Atom?

  If you use the time you now spend complaining to code instead, you should have the basics covered.

• by dingo_bat on 3/24/17, 7:45 AM

  Don't see this on my Win 10 ultrabook.

• by vgy7ujm on 3/23/17, 3:48 PM

  The answer:

  Vim <-- this

• by billconan on 3/23/17, 3:46 PM

  Yesterday I wrote a webpage with a bootstrap template. The webpage has a progress bar that is updated in realtime by a websocket. The webpage is extremely slow. I guess every bit of progress bar update it rerenders the entire dom tree.

  I don't think react would do much better, but I will have to try.

• by onli on 3/23/17, 3:33 PM

  Because it hasn't been mentioned yet, as far as I could see: Blinking cursors are horrible and should never exist, it resembles torture. http://www.jurta.org/en/prog/noblink is an extensive list with ways to deactivate it in various programs. Try it out, you will feel the difference.

• by drzaiusapelord on 3/23/17, 3:18 PM

  >A workaround for folks who are similarly obsessed about battery life

  That's odd wording. Obsessed because I don't want to waste energy, which leads directly to pollution? Or don't want a short battery life on my laptop? Power savings shouldn't be seen as irrelevant geekery.

  13% is half the capacity of a single core in a four core processor. My 5 year old 2500k peaks at 120 watts. So 15 watts to render a cursor?

  Microsoft needs to stop it with these terrible levels of QC. Its inexcusable.

• by LanceH on 3/23/17, 3:52 PM

  On one hand, I'm annoyed that javascript and browsers are being used for a text editor.

  On the other hand, I'm reminded of the arguments against emacs using 8 MEGS of memory and how terrible that is.

  I've learned to just relax and use what works. People have chosen to concentrate on extensibility at the expense of current day performance. The result has been good enough.

  There is probably something else to be said about these also making OSX a first class citizen, which hasn't always been true.