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

231–240 of 801 posts

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

#231

Post by gbuk2013 »

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 get that they are extensible, but is that really worth the slowdown to you?

Yes it is worth it. I use Atom, which people saying is slower than VS Code, but that's still fine and definitely worth it.

I used to use (and still use sometimes) vim but mostly just Atom with vim-mode-plus plugin.

It is possible to do all that Atom does in Vim and I have colleagues who are very productive with a heavily customised Vim but somehow, despite using it for years, I only ever used quite basic features. Now I can do the things in Atom that I could not bring myself to learn in Vim.

In any case, editor performance is the least of my worries. Most of my time is spent waiting for stuff to deploy and tests to be done, meetings etc. rather than actually writing code. :(

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

#232

Post by jdonaldson »

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

Except we're using divs, markup elements originally intended for research documentation, and using them to emulate modern UI techniques. I don't mind abstractions, but we should at least be using something built to task.

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

#233

Post by y4mi »

josefx wrote: post #145
cle wrote: post #42

Earlier quoted context omitted.

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.

So does it have a NoScript plugin to kill the unavoidable 200 tracking and ad scripts from Google, Facebook and who knows what running in the background? I am sorry if I offend someone with this, however the current Web experience is something I want as far away from my dev. tools as possible.

tracking or ad scripts by facebook or google are in neither atom nor VSCode.

both projects are open source if you care to verify

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

#234

Post by floatboth »

paulddraper wrote: post #208
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?

Don't vim, emacs, Sublime, and IntelliJ IDEA work on FreeBSD?

(neo)vim, emacs and IDEA certainly do. Sublime is not natively ported, only under the linux compat layer.

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

#235

Post by city41 »

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…

There really isn't much competition though. Sublime is commercial. Many people don't like emacs or vim. Most other editors are confined to one OS (Notepad++, Kate, etc).

When it comes to a full featured, modern editor that works quite well out of the box on most modern OSes, I struggle to come up with any answer other than VS Code.

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

#236

Post by pcarolan »

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 tried VS code? It seems your arguments about performance are theoretical but in my experience i have run into none of what you're describing could happen on a 5 year old macbook air. A 14% cpu idle due to a cursor is a bug that will be squashed. The software experience, in practice, is quite impressive.

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

#237

Post by antisthenes »

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

Excel loads in ~1 second...and doesn't have UI lag after it does.

Try working with large data sets in Google Docs and you'll have that 2-3 second lag time with _every_ operation you perform.

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

#238

Post by rvern »

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…

> Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform.

Actually, it would take one hour because you would use Poppler, and it would be cross-platform. It would also be faster than pdf.js.

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

#239

Post by hasenj »

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 used to think the same, until I started using VS code and it completely blew me away!

I don't care if it's written on to of a browser or in assembly. I just know it's the best text editor I've used so far.

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

#240

Post by stickfigure »

thechao wrote: post #129
cr0sh wrote: post #112

Earlier quoted context omitted.

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

Except that the abstraction layer for the user has remained the same. The extra abstraction layers you're talking about are invisible to the user... while our GUIs are slower, and our processors faster. It feels like, after 30 years, we should be able to have our GUI cake and eat it, too.

Except that the abstraction layer for the user has remained the same.

This is absolutely not true.

Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos (or control-control sequences for WordStar users like me).

Going from desktop apps to webapps changed the abstraction layer of how we access and share documents. No more installing software on the desktop. Docs are available on every computer we log into. Multiple people can edit the same document.

Maybe you don't care about document sharing and would be happy installing old school word processors and spreadsheets? That's a fair statement to make, but the market appears to be voting otherwise.

Post reply on HN