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

151–160 of 801 posts

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

#151

Post by abritinthebay »

Philipp__ wrote: post #81
randiantech wrote: post #59

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.

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

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

#152

Post by jacquesm »

cuckcuckspruce wrote: post #143
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...

It depends on what efficiency buys you, and what you trade efficiency for. When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness. For some applications, even today, when maximum efficiency is necessary, purpose built machines ('soldering together the flip-flops that ma…

> When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness.

And in many cases that led to an instant drop in productivity. Those old green-screen systems were not pretty but they were quite efficient to use.

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

#153

Post by coldpie »

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.

Yeah. I remember when Gmail introducing the floating compose window with some limited window management was a big feature. But, desktop GUIs have been doing this since the 80's...

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

#154

Post by pyre »

cr0sh wrote: post #120
onion2k wrote: post #88

Earlier quoted context omitted.

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.

...a whole 2-3 seconds! Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud... I know that's a generalization, and most likely unfair - but damn, today's phones, to this old man, are pocket super-computers (for that matter from my vantage point, an Arduino is a wonder, and a RasPi is utterly amazing)!

> Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud...

At the same time, we are now living in the future. With "pocket super-computers" that are more powerful than the Crays that existed when you were waiting on 300 baud text rendering, yet we are using 13% of that power just to render a blinking cursor? Does that not seem like we haven't made as much progress as we should have?

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

#155

Post by TeMPOraL »

cr0sh wrote: post #120
onion2k wrote: post #88

Earlier quoted context omitted.

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.

...a whole 2-3 seconds! Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud... I know that's a generalization, and most likely unfair - but damn, today's phones, to this old man, are pocket super-computers (for that matter from my vantage point, an Arduino is a wonder, and a RasPi is utterly amazing)!

That's totally unfair. You should compare it to startup time of Word from, I don't know, 10 - 20 years ago. Around the same time (if not less), and Google Docs still can't match the features of old Words.

The point being, for the past decade or two, we've been burning all hardware performance improvements on things that are neither visible to user, nor enable them to do more with their computer. Surely, there must be ways of spending those CPU cycles and RAM bytes on things that are actually useful and enable people to do more / better / faster work.

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

#156

Post by [deleted] »

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.

[deleted]

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

#157

Post by pas »

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 simply cannot understand why Atom and VSCode are so popular.

Free, open source, best ide for TypeScript, and better than Eclipse, NetBeans.

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

#158

Post by throwasehasdwi »

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.

Javascript is meh, it's HTML and CSS that are the real culprits for the crazy inefficient GUI rendering. HTML was great for what it was designed for, but we're ten years beyond that.

Something will come in and replace HTML, it's just a matter of time. The main driver is mobile. The many layers of abstraction burn battery, one day phone manufacturers will get tired of it and do something.

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

#159

Post by billconan »

Touche wrote: post #41
artursapek wrote: post #25

I'm reminded of this classic: https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't a…

I think I don't understand the issue well enough. This looks like a standard blinking cursor to me. Users expect a blinking cursor in an editable text field. I'm not sure why this implementation is slow or why they needed to implement it themselves and not let the OS handle the blinking cursor. I'm guessing there must be some reason.

this is exactly the same problem I met yesterday.

I made a webpage based on a bootstrap template

On this webpage, I have 2 realtime components. one is a chart, based on dygraphs

the other component is a bootstrap progressbar.

the bootstrap progressbar is made by html divs:

https://www.w3schools.com/Bootstrap/bootstrap_progressbars.a...

Both components are updated in realtime by a websocket.

I noticed that the chart by itself is very fast. But as soon as the progressbar is added, the entire webpage and even the entire machine becomes very slow. I guess this is because every bit of progressbar update, the browser rerender the entire page, as the progressbar is a div.

I don't know how to solve this. I thought about using react for its virtual dom. but if eventually I need to update the dom, the speed seems to be the same.

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

#160

Post by dvdcxn »

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.

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 the javascript it executes in order to control the rendering of its html/css, rather than the rendering itself.

Post reply on HN