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

51–60 of 801 posts

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

#51

Post by randallsquared »

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.

That depends strongly on the IDE and the user. I used to pay Jetbrains every month, but last July I noticed that I preferred VS Code to PHPStorm for essentially everything, and stopped my subscription and uninstalled it.

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

#52

Post by tinus_hn »

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…

iTunes has the same issue with its spinner while syncing, it takes about 20% CPU time.

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

#53

Post by jbmorgado »

voxic11 wrote: post #26
nihonium wrote: post #21

Earlier quoted context omitted.

On the other hand, iPhone's "Clock" app has an icon that shows the correct time with a super smooth seconds indicator. Which doesn't drain the battery.

How fast does it run on 1995 hardware though?

Pretty sure any sane software implementation of a simple seconds pointer would easily update faster than 1 Hz while using little to negligible CPU time in a Desktop processor from the 90's and onwards.

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

#54

Post by jjuel »

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

As plugins go Sublime has quite a few as well. In fact there hasn't been one I've looked for and couldn't find. I used to use Atom and VS Code, but Sublime is just that much quicker even for day to day tasks as you say. Plus plugins can be written in Python so that is a huge plus. But as with anything use what makes you happy.

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

#55

Post by nolok »

Touche wrote: post #41
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.

> I'm not sure why this implementation is slow

I'm guessing the culprit for that is in this part of the bug report:

> Zooming into a single frame, we see that while we render only 2 fps, the main thread is performing some work at 60 fps (every 16 ms)

As for

> why they needed to implement it themselves and not let the OS handle the blinking cursor

They're not editing inside a text editor field anymore, they need to blink on html. I guess they're not using a deprecated tag is because it's not customizable in any way.

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

#56

Post by mmarks »

13% cpu usage at the lowest c-state is a also very different than 13% at an elevated c-states. I've recently spent a lot of time analyzing c-states/p-states and the power mgmt modes of the GPU. After learning more about the complexity behind the clocks, bus speeds, etc. underlying each state, whenever I hear someone quote a utilization number of a minor workload, I want to know at what power state.

Not to take away but the author's point, just an aside that utilization numbers can be a lot more complicated when there are dozens of energy states and the utilization might be utilization at a particular state rather than utilization at maximum power

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

#57

Post by azrazalea »

Touche wrote: post #41
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.

> why they needed to implement it themselves and not let the OS handle the blinking cursor.

Probably because they are using electron.

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

#58

Post by therealmarv »

dheera wrote: post #40
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…

Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.

Would be better to compare it to transfer a state/screen over the wire/internet on 486 vs. doing the same nowadays ;)

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

#59

Post by randiantech »

Philipp__ wrote: post #28
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.

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...

VS Code IS a viable option. I use it daily basis and works great.

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

#60

Post by awinder »

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…

I switched to vscode from webstorm, for performance reasons. Building a native editor / ide is a great idea. But since a lot of options in this area had already chosen some cross-platform toolkit for development, why not build it as an electron app?
Post reply on HN