Slashdot Mirror
Blinking Cursor Devours CPU Cycles in Visual Studio Code Editor (theregister.co.uk)
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.
13 per cent CPU. For a blinking cursor. That's... impressive.
But not in a good way
"She's furniture with a pulse"
...when you hand the task over to the HALO crew. Absolutely NO flicker, man. Oh, wait...
13% of CPU at 60 fps. Maybe they shouldn't use Javascript and a cross platform framework for drawing the cursor. ;-)
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.
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.
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...
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.
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!
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.
It duplicates functionality and kills performance
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."
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.
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.
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.