Slashdot Mirror

← Back to Stories (view on slashdot.org)

Blinking Cursor Devours CPU Cycles in Visual Studio Code Editor (theregister.co.uk)

Posted by msmash on from the behind-the-scene dept.

An anonymous reader shares a report on The Register: Microsoft describes Visual Studio Code as a source code editor that's "optimized for building and debugging modern web and cloud applications." In fact, VSC turns out to be rather inefficient when it comes to CPU resources. Developer Jo Liss has found that the software, when in focus and idle, uses 13 percent of CPU capacity just to render its blinking cursor. Liss explains that the issue can be reproduced by closing all VSC windows, opening a new window, opening a new tab with an empty untitled file, then checking CPU activity. For other macOS applications that present a blinking cursor, like Chrome or TextEdit, Liss said, the CPU usage isn't nearly as excessive. The issue is a consequence of rendering the cursor every 16.67ms (60 fps) rather than every 500ms.

32 of 236 comments (clear)

  1. Holy Blinking Cursor, Batman! by BeerCat · · Score: 5, Funny

    13 per cent CPU. For a blinking cursor. That's... impressive.

    But not in a good way

    --
    "She's furniture with a pulse"
    1. Re:Holy Blinking Cursor, Batman! by drnb · · Score: 4, Insightful

      13 per cent CPU. For a blinking cursor. That's... impressive. But not in a good way

      This is why coding tests are given during job interviews.

    2. Re:Holy Blinking Cursor, Batman! by number6x · · Score: 5, Interesting

      Reminds me of the map of system calls in Apache vs MS IIS. An exercise in design analysis.

    3. Re:Holy Blinking Cursor, Batman! by lgw · · Score: 4, Funny

      Yeah, my old Commodore 64 had a blinking cursor, and it somehow managed that remarkable feat with an 8-bit 6510 CPU running at 1MHz!!!

      Behold the power of Javascript! It gives a modern PC with 8-16 GHz of total CPU ... less actualy processing power than a Commodore 64.

      Well done JS engine guys. Well done.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    4. Re: Holy Blinking Cursor, Batman! by Anonymous Coward · · Score: 5, Insightful

      There's a difference between remembering the piece of trivia that is the name a certain environment calls a concept and understanding the concept.

      The question becomes: are you looking for a software engineer, a computer programmer, or a trivia expert?

    5. Re:Holy Blinking Cursor, Batman! by CanadianMacFan · · Score: 4, Insightful

      "What is the Liskov substitution principle?"

      I didn't know what it was until I looked it up in the article. So basically you want me to remember that some guy came up with a name for using inheritance and if I don't remember it I'm a bad programmer?

      Test to see how the person will fit into your team because no matter how great they are if they disrupt how the team works. Then for programming skill and then for things like remembering the exact definition of terms that they could use Google to get.

    6. Re: Holy Blinking Cursor, Batman! by Darinbob · · Score: 3, Interesting

      I agree there. I have used many programming languages and so many of them make up their own terms for things that were previously well known by different names in the industry. Most of these new terms were for things that were known in the 70s and 80s. I think a lot of people who are in their own bubble, making up their own terms, without knowing what goes on elsewhere.

    7. Re:Holy Blinking Cursor, Batman! by Anonymous Coward · · Score: 4, Insightful

      13 per cent CPU. For a blinking cursor. That's... impressive.

      The failure to understand anything more than any one level of the stack is the root cause of the problem:

      In fact, I'm willing to bet it's not a coincidence that it's 13%. It's likely 12.5%, as in 100% of one thread on a quad-core CPU with hyperthreading enabled, then rounded up to 13% for the presentation in the task manager. On a dual-core with HT, it'd be 25%, on a dual-core without HT, it'd be 50%, and if anyone can get it to run on an old single-core Pentium IV or something it'll just peg that CPU.

      People would have to know something about hardware to figure that out, and webdevs, well, they just... don't.

    8. Re:Holy Blinking Cursor, Batman! by sexconker · · Score: 3, Insightful

      That's because most "programmers" are utter crap. They don't know their tools. They don't know the language that the program in. They don't stay up-to-date.

      I don't "know the tools" or "know the language" until I'm fucking using them. Then I google whatever the fuck it is I need to do using whatever the fuck it is some clown has put in front of me, RTFM, and get it done. Interviews test for the dumbest fucking shit. I for one generally don't care what fucking language or environment I'm in. With documentation (the fucking internet 99.9% of the time) learning how to do X in Y is trivial. Knowing that you need to do X instead of x is the trick. When you give an applicant a test to do X in Y, you're just testing if they know Y and maybe if they have memorized X. You're not finding out if they understand anything or can think critically.

      They cannot reason about problems. 95% can't do the simplest of problems. You have to really deep before you find people who can talk about design principles, design by contract, etc.

      When your "problems" are all pulled from the same "Shitty Questions and Tests for Shitty Interviews" site/book, what do you expect? If you're looking for people who talk about "design principles" or "design by contract", you're retarded. There are only three design principles: Correct, secure, and fast. There is only one design contract: Deliver X for $Y. If you don't understand what X is or why it's X and not x (even if the customer doesn't, or if the customer asks for X when they need x) then you're gonna have a bad time. See Oracle and IBM and anyone who's ever contracted with them.

      You're getting mindless applicants because you're asking mindless questions. You cannot discern a competent programmer/developer from an incompetent one because you're looking for memorization, certifications, etc. Of course, the people conducting the interviews are typically not competent programmers/developers, so they don't know what else to look for or how else to evaluate applicants.

    9. Re:Holy Blinking Cursor, Batman! by Anaerin · · Score: 4, Insightful

      Opening VIM is the easy part. If you can successfully CLOSE VIM afterwards, that's the passing point.

    10. Re:Holy Blinking Cursor, Batman! by avandesande · · Score: 4, Insightful

      Obviously the OP suffers from incredibly lazy thinking to believe that he can find a good candidate with just a couple of questions. You certainly don't want to work there.

      --
      love is just extroverted narcissism
    11. Re:Holy Blinking Cursor, Batman! by bored · · Score: 3, Funny

      You probably just made it consume 100% of the CPU as it tries to flash the cursor at an infinite rate...

    12. Re:Holy Blinking Cursor, Batman! by arglebargle_xiv · · Score: 4, Funny

      "Tell me what a class invariant is."
      Blank stare.
      "What is the Liskov substitution principle?"
      Deer in headlights.

      Prove that every even number > 2 can be expressed as the sum of 2 primes

      Empty look.

      Show that the Riemann zeta function has its zeros only at the negative even integers and complex numbers with real part 1/2.

      Panicked expression.

      Demonstrate that If k graphs each having k vertices have the property that every pair of complete graphs has at most one shared vertex then the union of the graphs can be colored with k colours.

      Runs from room.

      Sigh, kids these days...

    13. Re:Holy Blinking Cursor, Batman! by drnb · · Score: 3, Funny

      Opening VIM is the easy part. If you can successfully CLOSE VIM afterwards, that's the passing point.

      Extra credit for a minimal number of beeps while using it. :-)

  2. That's what you get... by Kormoran · · Score: 4, Funny

    ...when you hand the task over to the HALO crew. Absolutely NO flicker, man. Oh, wait...

  3. Maybe they shouldn't use Javascript ... by drnb · · Score: 5, Funny

    13% of CPU at 60 fps. Maybe they shouldn't use Javascript and a cross platform framework for drawing the cursor. ;-)

  4. Probably a minor oversight. Will likely be fixed. by Anonymous Coward · · Score: 5, Insightful

    Seems like a minor oversight. It will probably be fixed soon, if it hasn't already been.

    Microsoft has actually done a good job with Visual Studio Code. It's a lot better to use than, say, Atom or EMACS. It has some great plugins, they're easy to install, and overall it provides a good compromise between a plain text editor and a full-featured IDE.

    I'm not going to hold this minor bug against them.

  5. Devil in the Details... by EndlessNameless · · Score: 5, Interesting

    Is it rendering the cursor specifically at 60 FPS, or is it the entire active window?

    Because I can imagine a good reason for rendering the active window in an IDE every frame. Your brain is definitely capable of registering visual changes faster than once every 500ms.

    If you have smart syntax highlighting, you want the squiggly lines, tab-complete indicators, color coding, and highlights to appear ASAP. The sooner you notice a mistyped function name, the less characters you have to back over to fix it.

    A fast, responsive window refresh is essential to modern IDEs.

    I mean, feel free to call them out if Eclipse or whatever is much better at it, but I can totally see why they would rerender the entire window. If it is the active window (per the summary), then you can assume it's being used and therefore deserves the most responsive output possible.

    --

    ---
    According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
    1. Re:Devil in the Details... by drnb · · Score: 3, Insightful

      Is it rendering the cursor specifically at 60 FPS, or is it the entire active window? Because I can imagine a good reason for rendering the active window in an IDE every frame.

      Pro tip: when rendering an entire window, or an entire screen in a game, you might want to consider "dirty rectangles" and only redraw what has changed.

  6. Re:I think there is more to it. by RatherBeAnonymous · · Score: 3, Informative

    According to TFA, adding "editor.cursorBlinking": "solid" to the app's settings.json fixes the high CPU consumption. That makes me think there isn't anything more to it.

  7. Re:Probably a minor oversight. Will likely be fixe by Richard_at_work · · Score: 4, Interesting

    It looks like its actually an underlying issue with Chromium, which is what powers Electron, the UI framework which VS Code is based on.

    https://bugs.chromium.org/p/ch...

    Simple CSS Keyframe Animation Causes Too High CPU Usage

    Steps to reproduce the problem:
    It happens on my Mac.

    Demo page here: http://output.jsbin.com/vogaxa

    Add a simplest keyframe animation to an element and Chrome will use 5-6x more CPU than it should.

    e.g: .blinking { animation: 1s blink step-end infinite; }

    @keyframes "blink" {
        from, to { visibility:hidden; }
        50% { visibility:visible; } }

    What is the expected behavior?
    CSS animation should consume equal (or close to equal) CPU load than its Javascript animation alternative.

    Javascript setInterval consumes around 1.2% CPU on my Mac (Chrome's task manager)

    1.2% for Javascript animation of a blinking cursor btw is the same usage that I get with no animation and the default cursor inside an input element.

    CSS animation should produce the same results.

    What went wrong?
    CSS keyframe based animation consumes 7-8% CPU which is unjustified for such a simple case.

  8. 60 FPS is the minimum these days by tobiasly · · Score: 5, Funny

    Well I would hope that a modern IDE released in 2017 would have 60 FPS! I also have the 4K cursor, HDR cursor, 3D cursor, Retina cursor, and VR cursor plugins all enabled, but I realize that may be overkill for some people. As soon as I get my new water cooling rig set up it'll be buttery smooooth.

  9. Re:Is it a good test? by mark-t · · Score: 3, Insightful

    Using the CPU draws more power than if it were just idle, so it is incorrect to say it does not matter.

    --
    File under 'M' for 'Manic ranting'
  10. Re:Probably a minor oversight. Will likely be fixe by Tailhook · · Score: 5, Interesting

    Microsoft has actually done a good job with Visual Studio Code.

    If you're willing to completely dismiss performance concerns then yes, great work. On the other hand, if you care about performance, and memory usage, it's pretty hard to do worse than VSCode without including including something like Eclipse or Intellij in the survey.

    --
    Maw! Fire up the karma burner!
  11. Re:Probably a minor oversight. Will likely be fixe by Grishnakh · · Score: 5, Insightful

    No, it sounds like the problem is the insane idea of running local code through a web browser. The web itself is probably the most Rube Goldberg-esque way of displaying interactive data and controls to a user (HTML, a backend language like PHP/Java, a client-based language (JavaScript), and then a crappy markup language for style attributes (CSS)). It's understandable how it evolved, but it makes no sense at all to use this for local applications.

  12. don't use the 'web stack' for desktop applications by epyT-R · · Score: 5, Informative

    It duplicates functionality and kills performance

  13. Not a Microsoft Issue by nuckfuts · · Score: 4, Insightful
    Funny how the summary and the article both start by saying...

    Microsoft describes Visual Studio Code as a source code editor that's "optimized for building and debugging modern web and cloud applications.

    But then the article goes on to say...

    The underlying issue is with Chromium, which is a part of the Electron Shell (Visual Studio Code and others like Atom and Slack utilize this shell in their apps)"

    and then...

    Google Chrome product manager Paul Irish, posting to a thread on Hacker News, said, "Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval. I'm confident that the engineers working on Chrome's style components can sort this out, but it'll take a little bit of work."

  14. Re:Probably a minor oversight. Will likely be fixe by DickBreath · · Score: 5, Funny

    Please do not knock Emacs.

    Emacs is very popular. Popularity seems to correlate highly with the set of users who once started up Emacs, were unable to figure out how to exit from Emacs, then had no choice but to write Emacs Lisp extensions to accomplish all other necessary tasks.

    I don't think VS Code can make that claim.

    --

    I'll see your senator, and I'll raise you two judges.
  15. Re:Maybe I'm just out-of-touch... by epyT-R · · Score: 3, Insightful

    The constant unyielding unending march of useless abstraction.

    hardware (hypervisor) -> kernel (per process hardware abstraction for userland) -> interpreted runtimes (nodejs/java/.net etc).

    That last part is why modern 'apps' are bloated piles of garbage that need multighz machines to be responsive doing things that could be done on a 486 (eg winNT/mirc on a 486 vs discord on a haswell@4.7ghz). The argument is security and ease of development (zomg! cloud!). The former's been readily disproved and the latter sacrifices significant capability and performance. I think we're well past the point of diminishing returns and into the realm of significant drawbacks.

  16. Gloves off! by Kludge · · Score: 5, Interesting

    OK, buddy, vi vs. emacs flame wars were funny, and perhaps justifiable.
    But comparing VS to emacs?? No freaking way! Emacs totally kicks VS ass.
    And it never used 13% of my cpu to flash a cursor.

  17. Terrible interview questions ... by drnb · · Score: 4, Insightful

    What is the Liskov substitution principle?

    That is a very poor question. It exhibits the common naive programming test that is more of a trivia test, or basically a programming test derived from some old college quiz. Better questions ask people to perform relevant tasks or to discuss relevant problems. For example rather than ask about "Liskov", ask about the concepts involved:

    Q. A Square class is derived from a Rectangle class. Function foo has a non-const parameter of type Rectangle. Function foo is called with using a variable of type Square. Is this safe, if not why?

    Note that in the discussion they may inadvertently discuss class invariants.

    You say that some programmers do not understand or lack certain tools. The same is true for managers, and your hypothetical questions suggest that you may be lacking the tools necessary to conduct technical interviews and evaluations.

  18. Re:don't use the 'web stack' for desktop applicati by djbckr · · Score: 3, Interesting

    I partially agree. But I have a situation where I need to make a moderately simple app that reads/writes local files and calls out to utility command-line tools, and I need it to be cross-platform.

    I've researched high and low for a system that doesn't require me to learn a friggin huge framework (QT?), in a language I don't care to use (C/C++)** or an unreliable end-user setup (Python UI or Java Swing)

    I just need simple and I need it to work. Yes, Electron is bloated, but it's simple (to build apps with), it works on all platforms, and it allows me to build an app in a few days rather than a few weeks. And the performance for what I'm doing is perfectly acceptable.

    ** I don't dislike those languages, they are just overkill to get something simple done