Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VS Code uses 13% CPU when idle due to blinking cursor rendering

github.com

Post reply on HN
Print view View original

41–50 of 801 posts

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#41

Post by Touche »

artursapek wrote: post #25

I'm reminded of this classic: https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't a…

I think I don't understand the issue well enough. This looks like a standard blinking cursor to me. Users expect a blinking cursor in an editable text field.

I'm not sure why this implementation is slow or why they needed to implement it themselves and not let the OS handle the blinking cursor. I'm guessing there must be some reason.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#42

Post by cle »

dekhn wrote: post #22
paulddraper wrote: post #19

Earlier quoted context omitted.

> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.

you can do all of this in Qt, too. Without the overhead of the inner platform effect.

You can do it, but it's significantly harder. And with Electron, you can leverage the same skills that are used to build web applications to modify your environment and text editor as well. Those are very significant advantages.

Note: I don't use VS Code or any other JS editor, I use emacs. But I can definitely appreciate the major benefits of the architecture.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#43

Post by aphextron »

allover wrote: post #34
aphextron wrote: post #16

I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE. Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-p... Note that Atom and VSCode are nearly 10x slower than all…

As was pointed out numerous times in that thread, they aren't 'embarassing benchmark numbers', they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code. > But they have no place in text editing. Their popularity proves otherwise.

>they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code

I don't think that's true at all. I have tried both VSCode and Atom, and immediately dropped them both after they crashed opening a file of a few thousand lines.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#44

Post by jbmorgado »

paulddraper wrote: post #19
Philipp__ wrote: post #14

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…

> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.

Well, you can write plugins in Python for Sublime Text and NeoVim (and more). JS and Python and both fairly uncomplicated languages when it comes to "plebeian hackability/debuggability".

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#45

Post by [deleted] »

Philipp__ wrote: post #14

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…

[deleted]

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#46

Post by ralfn »

ygra wrote: post #15
okket wrote: post #2

TL;DR: It seems to be a problem in Chromium, the relevant CSS (one second change) results in a 60hz animation cycle. Workaround: "editor.cursorBlinking": "solid"

Interesting, considering that CSS animations were supposed to be much better than JS animations in that regard. I guess a simple setInterval would actually perform better here.

CSS animations and raw JS animations perform equally well. JS had a bad reputation for animation only because the common libraries back then (jquery, mootools) had absolute horrible incompetent implementations.

This also has nothing to do with the blinking interval. A setInterval would simply not do the same. The CSS animation is fading its opacity at 60 fps not toggling it. Doing the same with a setInterval(.., 1000/60) will use the same amount of CPU.

As any introductory tutorial about css animations explains: They interpolate between the percentages you are not providing! So thats a DOM update every 12ms. The reason its smooth is because opacity (like transform) does not trigger a relayout.

Finally, whatever is triggering relayouts is not the opacity change, but some other obviously badly written code that is continously triggered on requestAnimationFrame and is touching the DOM even though, zero dom writes should be taking place on idle. (And zero dom reads always! Since reading from the DOM triggers synchronisation between the rendering thread and the js thread)

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#47

Post by vvanders »

aphextron wrote: post #16

I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE. Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-p... Note that Atom and VSCode are nearly 10x slower than all…

Because for certain languages like Rust it is an IDE.

I was a bit surprised at those tests. It doesn't match my gut feel, VSCode is quite snappy for me.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#48

Post by kittenmittens »

paulddraper wrote: post #31
Philipp__ wrote: post #28

Earlier quoted context omitted.

And that is OK for Notes or todo app, but text editor that is used by developers who tend to customize it with plugins and whatnot I think that is not viable option. But that's just my personal preference, maybe I am wrong...

My two cents: you get what you pay for in your IDE.

Would you mind giving some examples, mostly for the higher tier of "paying".

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#49

Post by ApolloFortyNine »

tommoor wrote: post #29
aphextron wrote: post #16

I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE. Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-p... Note that Atom and VSCode are nearly 10x slower than all…

The benchmarks make it look bad but to be honest aren't that relevant for day-to-day use. I can't remember the last time I saw performance issues in Atom and the plugin infrastructure massively outweighs the occasional possible issue

The only ever time I see performance issues is when I accidentally click on a binary by accident. Atom's large file handling is awful... But how often do you open a 100MB text file?

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#50

Post by Philipp__ »

Touche wrote: post #35
Philipp__ wrote: post #14

It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…

> Wouldn't it be better to make native application Better in what way? The market has voted with their downloads, they don't agree that the problems with Electron apps are as bad as you feel that they are.

Are you kidding me? Look at the raw performances and benchmarks of Vim/Sublime/Emacs, compare it to VSCode and Atom and you will see. If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen.

And I still see native editors used more (for example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined). I don't want't my editor to crush mid session, or have to write bunch of gulp files and npm commands to do one simple modification.

Post reply on HN