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

131–140 of 801 posts

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

#131

Post by ovao »

Kiro wrote: post #122
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…

Have you used VS Code? Feels much more performant than any native editor or IDE I've ever used.

What native editors have you used?

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

#132

Post by LanceH »

On one hand, I'm annoyed that javascript and browsers are being used for a text editor.

On the other hand, I'm reminded of the arguments against emacs using 8 MEGS of memory and how terrible that is.

I've learned to just relax and use what works. People have chosen to concentrate on extensibility at the expense of current day performance. The result has been good enough.

There is probably something else to be said about these also making OSX a first class citizen, which hasn't always been true.

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

#133

Post by josefx »

tedunangst wrote: post #106
akerro wrote: post #63

Earlier quoted context omitted.

>> cross platform support > Yes. WOW FINALLY SOMETHING that will run on my LINUX and FreeBSD! ohh.. a lot of plugins don't support linux and it doesn't build on BSD?

Cross platform support means if you want support, you cross over to a supported platform.

Some years ago cross platform in Microsoft speak meant it would run on at least two of the following: A version of Windows, Wincows CE, Windows Phone or Xbox. That cross platform now almost includes a non Microsoft platform is progress.

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

#134

Post by squeaky-clean »

Philipp__ wrote: post #50
Touche wrote: post #35

Earlier quoted context omitted.

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

VS Code and Atom aren't really comparable for performance. VS Code is much, much smoother and closer to the experience of Sublime.

> or example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined

By this metric Notepad++ and Visual Studio (not Code) are the best editors because they topped out of every category (except Vim for Sysadmin / DevOps). If you look at the "Desktop Developers" tab, Visual Studio Code is actually in 3rd place behind Visual Studio and Notepad++. With Vim and Sublime a few rows down and Atom even further.

There's no way in hell Visual Studio (not Code) is faster than Vim, but how come it dominates it in all but one categories?

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

#135

Post by rayiner »

therealmarv wrote: post #94
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.

Also compare Google Docs with Microsoft Word and LibreOffice cold start up time. You will see 2-3 seconds is fast and the two mentioned are not even loaded from a remote resource...

If you don't have plug-ins, Word 2010 (which, even without plugins is far more functional than Google Docs) loads in under half a second on a modern machine.

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

#136

Post by ue_ »

nojvek wrote: post #38
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…

I don't know why you're saying they are slow. vscode starts up pretty fast. Sure it consumes more resources than vim. However having code completion, debugging, linting, and a bunch of IDE like features is super useful including the fact that it's cross platform and open source. It's very hackable. Just last night I fixed an issue that had been bugging me for a while. Pages with ads use a lot more of my CPU so I'm no…

To be fair, Emacs can easily have code completion, debugging, linting and a bunch of IDE features, it's cross platform and it's open source. It's probably one of the most hackable editors out there.

And I use adblock :)

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

#137

Post by andrepd »

Kiro wrote: post #122
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…

Have you used VS Code? Feels much more performant than any native editor or IDE I've ever used.

I guarantee that is virtually impossible.

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

#138

Post by gregmac »

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

If you want other developers to really take it up and build plugins, you have to make it easy to get into, so that means not just documentation, but great documentation, plus tutorials, examples and tooling to help.

You get a big chunk of that for free when you use HTML/CSS/JS.

Fire up VS Code, go to Help > Toggle Developer Tools, and poke around for a few minutes. Imagine the amount of time it would take to build a similar experience to just this one aspect if you were doing this from scratch.

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

#139

Post by pyre »

cr0sh wrote: post #112
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.

You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right? Ultimately, computing has always been one of abstraction from the lower "layers". Taken far enough, one could spuriously argue that if you aren't soldering together the flip-flops that make up your logic and memory, you just aren't being efficient...

There is a point to be made here though that is more valid than the argument against moving away from command-line DOS applications to Windows API applications.

Moving from text-based to graphical is a much different shift than what we are talking about here. The idea here is that we are creating many abstractions to get the same basic result. I can't rewrite Atom.io for DOS, but I could rewrite Atom.io to use the Windows API directly rather than being Electron-based.

We're talking about VS Code using 13% of the CPU while idle to render a blinking cursor. What benefit does the user get from this? We could render a blinking cursor with less then 13% of a much less powerful CPU years ago.

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

#140

Post by big_paps »

StyloBill wrote: post #107
drzaiusapelord wrote: post #30

>A workaround for folks who are similarly obsessed about battery life That's odd wording. Obsessed because I don't want to waste energy, which leads directly to pollution? Or don't want a short battery life on my laptop? Power savings shouldn't be seen as irrelevant geekery. 13% is half the capacity of a single core in a four core processor. My 5 year old 2500k peaks at 120 watts. So 15 watts to render a cursor? Micr…

It's a Chromium problem, maybe you should read the Github issue before commenting.

Still its one of the most interesting posts. x Joules per blink
Post reply on HN