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

81–90 of 801 posts

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

#81

Post by Philipp__ »

randiantech wrote: post #59
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...

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

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.

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

#82

Post by TeMPOraL »

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

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

Besides the X-server point, it's not just the state transfer that's causing web UI to lag.

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

#83

Post by aarongolliver »

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.

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

#84

Post by nottorp »

013a wrote: post #75
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…

Yeah! We should go back to native editors, like Eclipse or IDEA!

HN could use a "funny" upvote option...

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

#85

Post by juandazapata »

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…

100% of vim users will tell you that their vim setups also have code completion, debugging, linting, etc...

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

#86

Post by TeMPOraL »

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.

Compared to what kids these days use, it's as fast as a lightning bolt.

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

#87

Post by koolba »

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…

Because if we don't build it inside a web browser, we'll have to add plugin support to add a web browser inside of it. Then you have two problems.

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

#88

Post by onion2k »

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.

Google Docs takes a good 2-3 seconds to spin up a UI on my i7.

I doubt much of that time is spent building the DOM tree for the UI. Google Docs does a lot more than a simple text editing widget - there's a networked file system, a multi-user collaboration engine, a realtime notification system, etc that all get initialised. Instantiating all that over a network in 2-3 seconds is really fast.

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

#89

Post by juandazapata »

ApolloFortyNine wrote: post #49
tommoor wrote: post #29

Earlier quoted context omitted.

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?

It breaks for me when I open a 3MB json file with complex nesting.

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

#90

Post by naibafo »

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…

At least while I was using atom on a not so high end machine, it generally took a few seconds too start and being usable.

Neovim on the other hand is there in a heartbeat, and I do have completion, debugging, linting, file browsing, git integration... available as well :)

Post reply on HN