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.
Penguin fucking power engage!
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...
they're *flashing* and they're *beeping*. I can't stand it anymore!
“He’s not deformed, he’s just drunk!”
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...
The word "just" makes your claim unsustantiated. Nothing stated here verifies that other computations are not occuring.
This explanation seems very unlikely. Rendering a small line at 60 fps is much faster than that, even if hardware acceleration is not involved.
13% sounds like a single thread running continuously (no sleep/idle) on an 8-core CPU. Most likely it's just a bug where the thread is in an active loop, failing to go to sleep. It may be the cursor rendering thread, but that doesn't mean it takes all that time to render it at 60fps.
I understand that there was a bug that caused them to render the cursor at 60fps, but why does it take 13% of the CPU? I used to play games that rendered full frames at 30 or 60 fps, if only a cursor takes 13% I would expect that to be impossible. Something is terribly inefficient somewhere, way beyond just rendering too many fps.
Avantgarde Hebrew science fiction
you're a bunch of wankers. You *rely* on real engineers to build the CPUs to run your shitty code.
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.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Microsoft describes Visual Studio Code as a source code editor that's "optimized for building and debugging modern web and cloud applications".
The Hitchhiker's Guide to the Galaxy describes Visual Studio Code as a bloated pile of almost but not quite working spaghetti code written by ape descendants.
#DeleteFacebook
Microsoft Response: it's By Design
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.
This is also... fud. Process does not consume anything like 13% under the conditions described. More likely, the person had some extension installed that was either misbehaving, or some background processing was going on, like linting or indexing etc.
Netscape's founders have just assigned to Microsoft, all IP rights related to blinking text.
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()
}
}
Not this:
while true {
window.gdiPaint();
for child window.children {
child.gdiPaint()
}
}
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.
No doubt IntelliSense is being checked, there is background indexing of files, etc.
There's no possible way for this person to have profiled performance and found that blink_cursor() was responsible for 13% of the CPU load.
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.
In a world of the blind, the one-eyed man is king--and the two-eyed man is a heretic.
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?
It does seem true that software development practices "grow" to fit whatever amount of CPU resources are available.
Somewhat. It's mainly out of some performance bugs being harder to notice on the powerful testing hardware. Not malice, just impatience and not testing on the lower levels of consumer hardware.
As a prime example, one of the internal builds of Morrowind was absolutely beautiful, even by modern rendering standards. However, it could only run on Bethesda's development servers (or better hardware) and took a few DVDs to install. Many graphical aspects were traded down to make an XBox/PC dual release, but the result was still a good game and fit on a single CD with room to spare (the GotY version with Bloodmoon and Tribunal still fit on one CD). The biggest thing consoles have done for PC gaming is to keep the hardware requirements sane.
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.
How I wish I could mod you up!
(full disclosure: I do web development as part of my profession)
You know back in the day this used to be a solved problem, using hardware cursor functionality. But today everything has at multiple layers of abstraction that is JIT compiled into some universal binaries running on an emulated machine in your browser framework that is sandboxes from your OS with nine circles of separation from your hardware . You know, all in the name of progress..
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 cursor issue (which as a long time Visual Studio Code user I didn't even notice). It's easier to extend. The plugins that others have written are much better. It's a smaller initial download. It's easier to keep updated.
Then there's a native text editor like Gedit. One look at Gedit's UI makes me want to vomit.
Kate is perhaps the only native text editor that isn't a complete joke. But it's too tied to KDE to make it easily usable on non-Linux platforms.
I'd love to use a native or pseudo-native (like Java-based) text editor that offered the benefits of Visual Studio Code. But I've yet to find one that comes anywhere close to comparing to Visual Studio Code.
Rag on the technologies used to build Visual Studio Code all you want. All that I know is that it's a piece of software that works much better than all of its competitors.
What keeps PC gaming sane is that many gamers are using onboard video chipsets, integrated graphics. When you bring the hardware survey data to the graphics programmers and artists and show them how many current customers are using integrated intel video, the horror on their faces ...
Let devs have new boxes every two or three years, but let them keep their old system(s) for testing. Old systems that have that video card left by that visiting Nvidia rep removed, and that extra bank of RAM removed as well.
This is what happens when people try to build entire fucking desktop applications in Javascript. Some people really need to get it through their thick skulls that the entire computer is not a web browser and, as well, the web browser is not the only purpose of a computer.
Tried to replicate the issue. VSC CPU was between 0.2% and 0.0%.
Why to use CPU for that? It should be something for the GPU.
Check out firefox... just navigate to the titlebar (top of the window) and click and hold the left mouse button. You don't even have to move the mouse. It consumes 39% of my Core i5 in Windows 10. I have often marvelled at this.
and having writ, blinks on.
Have gnu, will travel.
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.
And they've been working on this for how many years?
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.
http://saveie6.com/
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?
http://saveie6.com/
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.
Perhaps this will lead developers to spare our machine resources--probably not.
https://www.youtube.com/c/BrendaEM
This is just Visual Studio for Apps asserting its appiness over LUDDITE software by taking CPU control away from the LUDDITE operating system! Only LUDDITES would hate this!
Apps!
. . .probably . . .
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, as opposed to a graph tree showing merges etc.
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.
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 the obvious "timer and XOR" that's been used since the dark ages. I'm guessing that timers and/or XOR aren't available in whatever API was exposed by the browser environment.
After that, it becomes less clear why it's so slow. Even though rendering a cursor frame-by-frame is still less efficient, it shouldn't be *that* inefficient. As others have pointed out, you have a dirty rectangle and an update 60 times per second. Maybe the underlying API is re-rendering the entire screen.
And that's how you get to 13% CPU to blink a cursor, and a lot of other things. That's why web apps keep sucking. It's a problem that can, in theory, be solved; but it won't be solved because it's a lot of work across many different organizations, each with different objectives all trying to hit a moving target of changing architectures and standards.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
That actually happened to me a long time ago. I was on a dumb terminal at a contractors site. I never used Emacs before and I needed to just write a few notes, I some how opened Emacs and then I couldn't figure out how to quit, save or get out... I ended up killing the process and opened vi instead.
I did later learn Emacs and used it all the time.
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
Okay, I've noticed that some people have read the article but does anybody think it's relevant that they are talking about vsc running on a mac?
OS: Ubuntu 17.04
Ran the steps, in the foreground, watching the cursor blink, 0% CPU used, 0.00.5s CPU time. Of course, I didn't have fucking chrome debugger running against my editor at the same time. Seems like the author of the "bug" doesn't know how to eliminate variables from a performance test.
I love how this discussion has devolved in to war of words by elitist programmers.
First, I just gave this a try and VS Code never exceeded 3% of CPU just sitting idle with the app in the foreground. I suspect if someone is seeing high CPU load on with the app just sitting there, it's attributeable to factors like either 3rd party plugins, or the app possibly doing some VCS checks in the background while idle (which it will do from time to time). Perhaps the user opened a rather large project and VS Code was indexing it in the background? Who knows. But I've never seen this type of behavior and I run VS Code thru it's paces every day.
Everything old is new again. A lot of DOS programs had a problem when someone tried to multitask them under something like DESQview or DoubleDOS since they were written to be run on a single-tasking computer and they would go into a tight loop when waiting for input from the keyboard (or modem, or whatever):
They used a tight getch() loop or something similar to keep re-reading the keyboard buffer until something showed up. And this would crank the CPU usage to 100%. Not a problem on a single-tasking DOS computer, but when you multitask it, issues obviously arise.
Programs like Tame (and a few others) were invented to control the keyboard polling interval and keep these programs from eating the whole computer when they are running in a multitasking environment.
If you're a zombie and you know it, bite your friend!
what about gitk?
I wonder if perhaps the causality derived from the test is a little flawed. So if there are only 2 threads running then fine...one for IDE and one for the cursor...but I doubt that's the case. This is like saying that a car can't idle @ 13% of the redline...and if it does then it's flawed.
and after 20 years of outsourcing, H1-Bs and a complete lack of protectionism... I'll get them.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
You're supposed to use your installer to create the environment you need. Python and Java can be installed locally to just your program, though I wouldn't recommend it as it'll make your download larger. People both love and hate that JVM feature.
You could have used Lua. Or you could have wrote a Batch script and Bash script then told the user to click one and if it doesn't display Ok then click the other one. Or better yet, your installer only installs the Batch or Bash version depending on the operating system and the user gets a nice shortcut to the program.
But in general I agree with you. If all the effort that has gone into the web instead when to a standardized application installation system, the computing world would be far ahead of where it is now and end users would have a superior UX.
The PAL extremists will never rest.
Long live 60Hz.
good ole m$ ...
This and a resource whore. Is why I don't use Atom.io based applications.
Hey, our questions to be asked during an interview are proprietary information!
Milton Thompson's book on the X-15 rocketplane program spoke of one of his colleagues flying the X-15 and a Navy officer.
The anecdote goes that after the X-15, the Navy interviewed him for serving as Executive Officer of a nuclear carrier. Why someone who was skilled at flying the hottest aircraft in the sky and in precision flying to collect aeronautical research data for the engineers, why that person should be promoted to second-in-command of a nuclear carrier is not clear, but the armed services are "up or out" in terms of career building and an officer does whatever the Navy tells them to.
Said Navy officer was subjected to one of these condescending interviews. Instead of the Liskov substitution principle it was something along the lines of knowing what to do if 6 of the 8 reactors were to malfunction. His response was that he didn't know and when scolded about it (it may have even been Rickover himself doing this), he replied that he would rely on his "Chief" (as in a Chief Petty Officer, the high-ranking enlisted person in charge of the ships Engineering section). When pressed on this, his further response was that if the Chief of Engineering or his immediate subordinates didn't know what to do, the ship was in deeper trouble than he as Executive Officer could do anything about.
Intellisense in Visual Studio has been hogging CPU and memory for over a decade. It's simply the cost of doing business in Visual Studio and the primary reason why I mostly use a simple editor and command line builds for WIN32 application/library development these days.
Blinking Cursor ...
+ scanning your drives for nude pix to post online, and vacation videos to insert commercials into.
Why didn't they just use the cursor stuff built into the OS software? Blinking cursor is really old stuff. Used to be I think it was 20 lines of code for an Apple 1.
How quickly can I go from "never heard of your app" to "in your app, with credentials"? With web, that takes 30 seconds. Click a link, wait for ~1.5MB, SSO sign in, and you're ready to go.
They have the galls to impose a 60fps limit! I'm going to code at 165Hz!
Riiight, because comparing "ed" to a full size IDE totally makes sense ... Not to mention, the issue discussed here is a Blink/Chromium issue and got nothing at all to do with VSC.