This article is more than 1 year old
Blinking cursor devours CPU cycles in Visual Studio Code editor
Crappy Chromium code is the culprit, we're told
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 per cent 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.
Eliminating the unwanted power drain can be accomplished by adding the following line to the app's settings.json file:
A more permanent fix will have to come from the open source Chromium project, though Microsoft has a solution of its own planned.
Electron apps rely on Chromium, the open source browser project, and Node.js for their browser runtime. As Microsoft VSC developer Peng Lyu points out in response to Liss's post, a similar Chromium issue has been reported. In fact, Chromium's animation handling inefficiencies go back further, to 2014 at least.
In an email, a Microsoft spokesperson pointed the finger at Chromium, in the most polite way possible. "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)," the spokesperson said. "Both our team and the community have contributed rich analyses in the GitHub issue, and there is an immediate workaround and a planned fix in that thread."
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. I think the added visibility on this topic will likely escalate the priority of the fix."
While excessive CPU usage may seem like a relatively minor problem, it's meaningful in the context of the tech industry's self-congratulatory narrative of continual improvement. New software features celebrated as efficiency gains look a lot less impressive when old software flaws that devour power linger on for years. ®