Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Software IT Technology

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

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.
This discussion has been archived. No new comments can be posted.

Blinking Cursor Devours CPU Cycles in Visual Studio Code Editor

Comments Filter:
  • by BeerCat ( 685972 ) on Friday March 24, 2017 @02:07PM (#54103975) Homepage

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

    But not in a good way

    • by drnb ( 2434720 ) on Friday March 24, 2017 @02:13PM (#54104037)

      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.

      • by number6x ( 626555 ) on Friday March 24, 2017 @02:22PM (#54104117)

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

      • That's why rapid prototyping skills are good for prototyping but are horrible at making a product.

    • by e r ( 2847683 )
      Said the actress to the bishop...
    • 13 per cent CPU. For a blinking cursor. That's... impressive.

      But not in a good way

      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!!!

      • by lgw ( 121541 ) on Friday March 24, 2017 @03:05PM (#54104447) Journal

        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.

        • by mwvdlee ( 775178 )

          You always blame the language authors' for crappy code written in the language?
          That's like blaming Shakespeare for what Trump says.

          • by lgw ( 121541 )

            The engine devs are not the language authors. I think the language authors are idiots, too, but not for any reason related to this story.

    • by Anonymous Coward on Friday March 24, 2017 @05:03PM (#54105203)

      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.

    • Preferences and then:

      "editor.cursorBlinking": "solid",

      Job done!

    • by Jeremi ( 14640 )

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

      Yeah, but the blinking cursor looks so much more realistic when rendered at a full 60 frames per second. It really gives it that extra "pop".

  • by Kormoran ( 859823 ) on Friday March 24, 2017 @02:07PM (#54103977)

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

  • by drnb ( 2434720 ) on Friday March 24, 2017 @02:11PM (#54104011)
    13% of CPU at 60 fps. Maybe they shouldn't use Javascript and a cross platform framework for drawing the cursor. ;-)
    • Um, excuse me? There is nothing wrong with using Javascript and a cross platform framework for drawing the cursor.

      Just be sure that each time the cursor is redrawn (even if it hasn't changed appearance from the last refresh) that you launch that Javascript environment in a fresh sandboxed VM. For safety. Think of the children.
  • by Anonymous Coward on Friday March 24, 2017 @02:12PM (#54104019)

    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.

    • 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... [chromium.org]

      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 [jsbin.com]

      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.

      • by drnb ( 2434720 )

        It looks like its actually an underlying issue with Chromium, which is what powers Electron, the UI framework which VS Code is based on.
        Simple CSS Keyframe Animation Causes Too High CPU Usage

        Well if this is the development approach for modern tools and applications I'm glad I splurged and upgraded to the i7 during build to order. It does seem true that software development practices "grow" to fit whatever amount of CPU resources are available.

      • by Grishnakh ( 216268 ) on Friday March 24, 2017 @02:43PM (#54104265)

        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.

        • by Anonymous Coward

          I've been a web developer for many years. I don't particularly like the entire web stack. Yes, it's shitty in many ways.

          But here's the thing: somehow, Microsoft has managed to make an advanced text editor that's responsive, extensible, and enjoyable to use on all of the major platforms. And they've done it using some of those web technologies.

          Visual Studio Code is an absolute pleasure to work with compared to IDEs like Eclipse or NetBeans or Intellij. It feels much faster than them, even with this blinking

          • Nah it's from Microsoft so it must suck! Enough said you heathen go use emacs like a good gnu like everyone else and gloat in your superiority of a better editor and wonder why anyone else hasn't come to your conclusions?

            • Of course, they should just change the User-Agent to "Microsoft Edge" and the CPU consumption will drop to 1%.

        • All the cool kids use node.js editors. Atom and brackets are no different in that regard as code. Can anyone verify if same bug appears?

      • Well IE 6 uses only 32 megs of ram. MS should silence the critics here and use vbscript and jscript then for the internals. No critics here for such a move then.

    • by Tailhook ( 98486 ) on Friday March 24, 2017 @02:42PM (#54104259)

      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 [github.com].

    • by DickBreath ( 207180 ) on Friday March 24, 2017 @02:54PM (#54104363) Homepage
      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.
      • by burhop ( 2883223 )

        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've always wondered how Emacs became my favorite operating system.

    • Gloves off! (Score:5, Interesting)

      by Kludge ( 13653 ) on Friday March 24, 2017 @03:52PM (#54104747)

      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.

      • by bored ( 40072 )

        Well emacs has regularly consumed 100% of my CPU syntax highlighting. Which I always excused it of (its lisp what are you going to do (shrug)), but looking at those editor benchmarks I had no idea that vim and a bunch of other editors are actually worse.

        Wow, if your editor consumes more ram and is slower than emacs then you are _REALLY_ doing something wrong.

      • And it never used 13% of my cpu to flash a cursor.

        Don't worry, I'm sure EMACs has a mode for it (and VI can emulate that mode).

    • 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.

      All joking aside, I will say that I quite agree with this statement. It's quickly becoming my go-to coding editor. Finally having a good experience that's the same on Linux and Windows is huge for me.

      I just hope that the Git visualization support (history, blame, diffs etc) gets better, either in the core product or via plugins. Nothing on Linux has come close to the speed, ease of use, and feature set of TortoiseGit for me. All the existing plugins seem to want to render the log history as a single list, a

  • I think that VSC is doing more then just blinking the cursor. Perhaps it's monitoring the keyboard for input, monitoring the file structure for changes, etc...
    • by RatherBeAnonymous ( 1812866 ) on Friday March 24, 2017 @02:23PM (#54104121)

      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.

    • Um, doesn't the operating system do that?

    • > Perhaps it's monitoring the keyboard for input, monitoring the file structure for changes

      Um, real operating systems, used by those who wear big boy pants, have APIs to give you a callback when there are changes to a folder you designate for watching.
    • by EvilSS ( 557649 )

      Perhaps it's monitoring the keyboard for input

      Let's hope they are not that amateurish. I've run into that in my job more than once but it's always been in a homegrown app vs commercial software (well commercial software written in the past two decades at least). Software using an entire core waiting for user input. Developer "I wonder if that's why my laptop fan turns on when I leave the application sitting" Ya think?

  • they're *flashing* and they're *beeping*. I can't stand it anymore!

  • by EndlessNameless ( 673105 ) on Friday March 24, 2017 @02:16PM (#54104063)

    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.

    • by drnb ( 2434720 ) on Friday March 24, 2017 @02:23PM (#54104129)

      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.

    • I smell a bug-fix at work here - something in the partial update rendering was not working on the first try, so they just render the entire window at 60fps and you never notice.

      Responsiveness is good, but nervousness is not. When I'm staring at a page of code, I expect it to be static - not wobbling around at 60fps.

    • You shouldn't be rendering a window every few milliseconds if it hasn't changed. This:

      function paint {
      if (window.changed) {
      window.render();
      }
      }

      function render {
      window.gdiPaint();
      # In Windows, most screen elements are "window"s
      for child window.children {
      child.paint()

    • You should be letting the OS do all that management. I don't want the cursor blinking at different rates in every application. Let me set it up in the system preferences and don't think you know better than I do. How fast the cursor blinks doesn't actually impact how fast the window is refreshed.

      Why are you wanting the red line to appear if you start to type a function name wrong? In Xcode when you start to type a function it lists all functions that match and as you continue typing the list gets smalle

  • by tobiasly ( 524456 ) on Friday March 24, 2017 @02:28PM (#54104165) Homepage

    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.

  • The blinking cursor render gets called every 16.67 ms because there is nothing else going on. So the cpu usage is 13% to render cursor and 87% idle. Unless there is a 13% additional cpu usage when I doing something meaningful, it does not matter.
    • by mark-t ( 151149 ) <markt@@@nerdflat...com> on Friday March 24, 2017 @02:39PM (#54104241) Journal
      Using the CPU draws more power than if it were just idle, so it is incorrect to say it does not matter.
    • by epyT-R ( 613989 )

      No.. 100/12.5=8. It's an 8 core (probably 4/8 HT). One core is being maxed out. Instead of idling, the code (chrome runtime) revolved around blinking the cursor is forcing the window context to refresh at the display refresh rate except only when it has to redraw (every 500ms).

    • Unless there is a 13% additional cpu usage when I doing something meaningful, it does not matter.

      13% CPU is the difference between a CPU going to one of its C-states. i.e. It's the difference between 8 hours battery life and 3 hours battery life on many laptops.

      You should be strung up by the short and curlies for suggesting that this kind of performance for a blinking cursor doesn't matter.

  • How is it that today's average 3+GHz 8-core badass CPU can be hobbled like that?

    My jerry-rigged 486 DX/4-100MHz machine of 20 years ago didn't have that problem. What the hell am I missing?

    My Pentium MMX 166MHz machine a year later was even less-handicapped.

    GPUs, SSDs, there should be no excuses ... what crucial bit am I missing? I'm serious. I haven't written any code in a very long time and something critical got overlooked.

    • by epyT-R ( 613989 ) on Friday March 24, 2017 @03:14PM (#54104517)

      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.

    • by TroII ( 4484479 )

      My jerry-rigged 486 DX/4-100MHz machine of 20 years ago didn't have that problem. What the hell am I missing?

      20 years ago, people weren't trying to write a friggin' IDE in JavaScript of all things.

  • by ZorinLynx ( 31751 ) on Friday March 24, 2017 @02:47PM (#54104297) Homepage

    How is it that four decades into the personal computing era and ANYTHING in the UI is using any significant amount of CPU?

    A blinking cursor?? The Apple II had a blinking cursor in 1977, and it was implemented in hardware. It used zero percent of the CPU.

    My gods, programmers have gotten lazy. What's next, extra CPU consumption for bold text? The system slowing down every time it beeps?

    • by myrdos2 ( 989497 )

      My system slows down every time it beeps. I added a sound effect to let me know when a batch script completes:

      powershell -c (New-Object Media.SoundPlayer "%exBinDir%\finished.wav").PlaySync();

      It locks for about five seconds before finished.wav starts beeping.

    • by Jeremi ( 14640 )

      My gods, programmers have gotten lazy. What's next, extra CPU consumption for bold text? The system slowing down every time it beeps?

      Or, we could at least allow for the possibility that the behavior was unintentional. If you've never written a program that inadvertently spins a core rather than correctly blocking while waiting for the next event in the event loop, then feel free to cast the first stone, but I imagine most programmers have made that mistake.

  • by epyT-R ( 613989 ) on Friday March 24, 2017 @02:51PM (#54104339)

    It duplicates functionality and kills performance

    • by djbckr ( 673156 ) on Friday March 24, 2017 @05:30PM (#54105357)

      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

  • by nuckfuts ( 690967 ) on Friday March 24, 2017 @02:52PM (#54104345)
    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."

    • 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."

      Why on earth would anything with a simple static 2D interface need to repaint every single frame? Yes, we can have nice animations - but does it really also need to refresh when no actual animation is going on? What madness is this? Who on earth writes a 2D gui framework and decides to just repaint at 60Hz whether the application is idle or not?

      At any rate, this goes a long way to explaining where our computer power went. Apparently selectively refreshing the screen, and only doing so when necessary, are no

  • and having writ, blinks on.

  • And they've been working on this for how many years?
  • Perhaps this will lead developers to spare our machine resources--probably not.
  • When there are so many layers between you and "the metal", it's just a matter of time before one of those layers creates a road block. You can get around these road blocks in at least two ways: 1. install native code and get to the metal, or 2. use less efficient techniques to get around the block.

    Taking route 1 means you can't claim "cross platform browser app" any more. Taking route 2 leads to slow code. It looks like MS chose route 2 and decided to use a frame-by-frame animation instead of using th

"One lawyer can steal more than a hundred men with guns." -- The Godfather

Working...