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.
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...
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
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.
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.
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 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."
Sounds like an accounting problem. Like why TaskManager uses 25% of cpu time.
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.
This. I do real time code and some of the things I've seen done make you want to ask the person who wrote the code if they thought about how it would be used for more than 5 seconds. Do no pre-optimize is not an excuse to be stupid. You do not need to run a sort routine inside an interrupt handler, even if it is only 5 elements.
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.
No, it's by customer request. Microsoft listens to its customers.
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
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
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?
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.
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.
Blinking Cursor ...
+ scanning your drives for nude pix to post online, and vacation videos to insert commercials into.
Penguin fucking power engage!
Why would you want to fuck a penguin?
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.
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.
> 13% sounds like a single thread running continuously (no sleep/idle) on an 8-core CPU
Thanks captain obvious.
The reason for it is still the cursor blinking ... or rather: chromium sucking at doing keyframe animations.