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

141–150 of 801 posts

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

#141

Post by makecheck »

Developers often work on extremely fast machines for their own productivity/sanity but this is a reminder that it can help to test on a slower setup from time to time. Or more generally, test edge cases.

For instance, if you have a graphics tool that briefly flashes screen updates, the problems are much easier to see. On a fast system, you might not only miss an unnecessary refresh of “everything”, you may miss a repeated refresh of the same content.

Also, on slower systems, the cost to generate a frame may delay an entire sequence. Consider something like “live resizing”: on your spiffy machine it seems fluid, on a lesser machine it might be stuttering like crazy. Sometimes you have to cheapen the computations occurring during rendering to make sure it’s OK.

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

#142

Post by cr0sh »

whazor wrote: post #108
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…

As someone who is literally building a IDE in Electron, the biggest reason is JavaScript itself. If you look to the stackoverflow yearly overview, you can observe that JavaScript is currently the most used language. Also do not forget about all the integrations you could do with for example devtools. An additional feature is that you can run the IDE in the web browser, so that you can have an online code editor. Thin…

I personally wish Github would incorporate a full-feature Electron-based IDE into their system; they do have an online editor, but it is fairly simplistic. Good enough for quick edits, but I wouldn't want to dev in it (then again, I started my professional career in software development sitting in front of a VT220 using a line-based editor; it got bad enough that me and my mentor had a "contest" on who could write a better full-screen code editor - honestly, we both won in a way).

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

#143

Post by cuckcuckspruce »

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

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 make up your logic and memory') are still used - it's just that it's often an ASIC that is fabricated.

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

#144

Post by JustSomeNobody »

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.

Where are the Michael Abrash's of today teaching people how to write tight, fast code? Seems a lost art...

Yes, I know, he's still around...

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

#145

Post by josefx »

cle wrote: post #42
dekhn wrote: post #22

Earlier quoted context omitted.

you can do all of this in Qt, too. Without the overhead of the inner platform effect.

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.

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

#146

Post by joshuamorton »

tomc1985 wrote: post #104

OH GOD NO Adding ANOTHER interpreted language to the pile? Jeeze you guys are crazy. Just STFU and learn C/Go/Java Does ANYONE in NodeJS world care about efficiency? Or does this "plebian" (ew! hacking is not plebian!) hackability trump all other concerns?

I think the fact that you call java not-compiled, but python interpreted shows your misunderstanding in this area. Both run exactly the same way, they are compiled into an intermediate bytecode which is run in a "VM". The normal Java VM has a JIT, the normal python VM does not, but pypy does and achieves performance on par with some of your compiled languages, at the cost of reduced c compatibility.

I know C, Java, python, and a limited amount of javascript and go. I prefer writing python. And, for plugins, there are enormous downsides to using something that is compiled (C, go).

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

#147

Post by darpa_escapee »

jamespo wrote: post #105
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?

> doesn't build on BSD doesn't run on ZX Spectrum either

Why bother describing something as cross-platform if this is the attitude held?

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

#148

Post by JustSomeNobody »

makecheck wrote: post #141

Developers often work on extremely fast machines for their own productivity/sanity but this is a reminder that it can help to test on a slower setup from time to time. Or more generally, test edge cases. For instance, if you have a graphics tool that briefly flashes screen updates, the problems are much easier to see. On a fast system, you might not only miss an unnecessary refresh of “everything”, you may miss a rep…

This ... isn't an edge case.

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

#150

Post by codr4life »

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.

There is plenty of available spectrum between native widgets and writing entire applications inside the web browser. Electron is a fashion statement and a convenient short cut to portability, that comes bundled with a mountain of complexity and technical debt. Moving the DOM to a native "server" removes most performance issues and allows applying the full power of a real language. https://github.com/codr4life/libc4dom/blob/master/tests/main...
Post reply on HN