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

171–180 of 801 posts

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

#171

Post by Philipp__ »

abritinthebay wrote: post #151
Philipp__ wrote: post #81

Earlier quoted context omitted.

I tried it too... Wasn't satisfied with performances. I used to install Atom every 2,3 months, when VSCode got released I then tried installing it every few months in place of Atom. I still do, but I always uninstall after few hours of using it. It has many good ideas implemented well, but still not worth switching and sacrificing all of the performance for nice git and debugging interface.

VS Code is faster than Atom (by... a lot) tho? Especially with large files, but just in general. Speed is the main reason I can't stay using Atom for more than a few hours. It's awful. VS Code is snappier than Sublime Text ffs...

Nope, it's not snappier than Sublime.

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

#172

Post by coldtea »

dvdcxn wrote: post #160
dheera wrote: post #40

Earlier quoted context omitted.

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.

I don't get this criticism. HTML/CSS is the closest we have to a universally understood syntax for designing interfaces. Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it. Any issues with performance is due to the implementation of the platform that renders this HTML/CSS interface. It's much more likely Google Docs feels sluggish due to th…

>Why invent a new standard?

Because they suck?

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

#173

Post by Touche »

trimbo wrote: post #80
Philipp__ wrote: post #50

Earlier quoted context omitted.

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…

This might mark the first time in history that Emacs was trotted out as an example of a performant editor. I say this as an Emacs user.

There's a lot of grass-is-greener comparisons happening. I'm a long-time Vim user and if I forget to turn off syntax highlighting before opening a large file it comes to a crawl as well.

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

#174

Post by fao_ »

gregmac wrote: post #138
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…

Building a plugin system is hard. Building one that allows creating complex UI elements, modifying other UI elements (from either the core app or other plugins) or changing the way literally anything is rendered is particularly hard. You not only have to build the code that supports all this, you also have to create and document an API and/or markup format to build all this out, plus document all your internal integr…

Or you could use Lisp, and have the UI be S-Expressions. Everything can edit a list

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

#175

Post by fenomas »

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…

Your question seems backwards. VS:Code is an absolute dream to use, for me at least - powerful, hackable, and performs great. If there are native editors that leave it in the dust, what are they? If there aren't, surely it would make more sense to ask why that is, rather than asking why Code isn't native?

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

#176

Post by mmarks »

aarongolliver wrote: post #83
mmarks wrote: post #56

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 b…

You mean p-states in your first sentence, right? Anything but c0 represents different levels of 'retiring no instructions' (totally idle). The rest of your comment seems accurate though.

You're correct that I just meant a lower power state.

The author mentioned blinking cursor, so it reminded me of graphics issues. A more efficient CPU state has the possibility of slowing an app due to CPU-GPU sync points. A blocking CPU in an energy efficient state can reawaken slower from GPU done notifications, so FPS is lower. So both c-state and p-states can affect performance. General point was just utilization may not be utilization at max power.

I've worked on problems where utilization was 15% at lower power and it was a problem. But to compare different workloads, it'd be < 1% at max power.

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

#177

Post by dvdcxn »

coldtea wrote: post #172
dvdcxn wrote: post #160

Earlier quoted context omitted.

I don't get this criticism. HTML/CSS is the closest we have to a universally understood syntax for designing interfaces. Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it. Any issues with performance is due to the implementation of the platform that renders this HTML/CSS interface. It's much more likely Google Docs feels sluggish due to th…

> Why invent a new standard? Because they suck?

Care to argue why? Also, there are countless alternative languages to compile down to HTML or CSS available. Feel free to create your own if none agree with your personal leanings.

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

#179

Post by coldtea »

StreakyCobra wrote: post #168
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…

By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology…

>By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one

You know where else you could do the exact same thing AND have a 10x faster and 10x more memory/battery efficient editor?

If a native editor just gave you a webview that can run JS extensions...

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

#180

Post by Philipp__ »

StreakyCobra wrote: post #168
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…

By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology…

One of the nicest replies here. Thanks! :)
Post reply on HN