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.
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.
Reminds me of the map of system calls in Apache vs MS IIS. An exercise in design analysis.
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 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 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!
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.
I hire C++ developers. I give a simple coding test to all applicants. 95% of all coders fail even the simplest of tests. There's a reason that trivial tests like FizzBuzz are used during programmer interviews. 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. 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.
"Tell me what a class invariant is."
Blank stare.
"What is the Liskov substitution principle?"
Deer in headlights.
Thank you for your time.
I work in the financial industry. We pay shit-tons of money if you know how to engineer software. But even here the talent pool is miserable.
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.
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.
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