Live data from Hacker News

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

github.com

121–130 of 801 posts

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

#121

Earlier quoted context omitted.

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.

Well I don't run any plugins in (neo)Vim besides colorscheme, FZF and neomake, and I run neovim inside Terminal.app since it is much faster than iTerm2.

One situation, I open 5k LOC file, scroll to the middle and bam colors are there everything was instant. In VSCode I open same file, slight delay, opens the tab, I click on middle of side codetree, slight delay, and few seconds for colors to draw. This is just one example. And there are those slight delays all over the place that I don't have with sublime, emacs or vim.

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

#122

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.

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

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

even the best case scenario is 13% of ~900MHz, 100MHz to blink 20 pixels.

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

#124
post #38

Earlier quoted context omitted.

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

Sure, but I won't pretend that adding those features doesn't add some significant resource usage and some occasional slowdown.

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

#125

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.

I pay a lot of money for my copy of IntelliJ.

...indexing...

...as I was saying...

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

#126
post #38

Earlier quoted context omitted.

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…

>I don't know why you're saying they are slow. vscode starts up pretty fast I takes "ages" to start up, meaning it interrupts my workflow. I like vscode, but startup time for the app and for new windows is terrible (~2 seconds) and it's one reason why I still prefer sublime for anything that doesn't have significantly better language plugins in vscode.

I so very rarely close Atom, and generally don't use multiple windows in a single app, that those slowdowns never really bite me. It'd be interesting to see their analytics to see how often people actually hit these things in practice.

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

#127
post #80

Earlier quoted context omitted.

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.

Emacs takes 8-15 seconds to open on my new i7. That matters when I just want to do quick edits. Vscode takes 3.

For me Emacs opens up in about 2 seconds and it's ready to go and print text input in scratch buffer. I am on 2015 MacBook Pro 13" with i5.

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

#128
post #35

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…

> 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 really comparing the number of people with VS Code to the number of people with Sublime, VIM, NotePad++, or Emacs and saying VS Code is greater?

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

#129
post #112
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 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.

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

#130

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…

The web is in just a shameful state. Even with 300 mbps fiber internet most websites are not snappy. As in, pages are so slow to render that I'll start reading, but then lose my place when the page reflows as it continues to load. Or click on the wrong thing because the page reflowed while I was trying to click on something.

As far as I can tell I'm actually CPU-limited, because I noticed no real difference from when I had 50 mbps internet. This is on a quad-core Macbook Pro that boosts up to 3.5 GHz...

Post reply on HN