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

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by allenz on Thursday March 23, 2017 @04:51PM (#13944130)

I enjoyed your comment. The non-funny response is that all GUI layers suck, possibly because visual interfaces and abstract code are inherently incompatible. Since no one has managed to make the perfect GUI, we constantly look to improve on the tradeoffs we must make, which are different for different applications. 13% idle sounds egregious but higher battery usage isn't a problem for most if it excels in the areas that matter: responsiveness, design, power, completeness. In contrast, Wayland improves not just idle, but also overall performance, which is the main consideration for a low level API.

[ Parent | on HN ]

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by chetanahuja on Thursday March 23, 2017 @08:40PM (#13945637)

"3% idle sounds egregious but higher battery usage isn't a problem for most"

Oh God this is why we can't have nice things. How the heck is someone actually justifying this stupid shit here?

[ Parent | on HN ]

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by allenz on Thursday March 23, 2017 @10:43PM (#13946190)

What do you find stupid? The way I see it, HTML/JS is a pretty good higher-level GUI language, and much effort has been spent making it work well. The overhead is worth it if it makes developers more productive.

[ Parent | on HN ]

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by TeMPOraL on Friday March 24, 2017 @07:25AM (#13948162)

Is it? The costs which you offset with developer productivity get multiplied times the number of users, which is orders of magnitude more than number of developers.

[ Parent | on HN ]

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by allenz on Saturday March 25, 2017 @05:46AM (#13954791)

And value delivered also gets multiplied by the number of users. VS Code users decided that they like it even after accounting for Electron. Clearly, then, VS Code has certain strengths, and I'd argue that some of those strengths are made possible by Electron. Second, great design requires experimentation, and Electron makes it easier to experiment with editor UI. VS Code could become a place to prototype ideas that eventually improve your more efficient editor.

[ Parent | on HN ]

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by rimliu on Friday March 24, 2017 @07:26AM (#13948173)

Why I agree on "much effort has been spent" it is very hard to agree about HTML which was meant to be used for marking up static documents combination with ad-hoc scripting language being "pretty good" for GUI. More like "possible to work around a bit".

[ Parent | on HN ]

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by elsurudo on Friday March 24, 2017 @06:36AM (#13947956)

Fair enough, but double-digit usage of an entire core... when the program is IDLE? how can you justify that? That's just broken.

[ Parent | on HN ]

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by allenz on Saturday March 25, 2017 @06:00AM (#13954831)

They will indeed fix this. At minimum, they can freeze the editor when it's out of focus. So there is no need to justify--this is a minor oversight, as someone phrased it over at Slashdot.[1]

I was responding to those who believe that this demonstrates a fundamental flaw in using Electron. My response emphasizes the tradeoffs involved. If they couldn't fix it, 13% background is undesirable, but it's not a dealbreaker for me if there are redeeming qualities. And it seems that VS Code certainly has some redeeming qualities.

[1] https://developers.slashdot.org/comments.pl?sid=10406465&cid...

[ Parent | on HN ]

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by andreareina on Friday March 24, 2017 @09:22PM (#13953541)

> higher battery usage isn't a problem for most if it excels in the areas that matter

As engineers it's our responsibility to not spend our users' resources unnecessarily. This thinking is how we got to the bloated web where pages need a megabyte (or several) of code just to render. Could you imagine an architect saying, "yeah, this design costs 2x that other one, but my clients are rich so it doesn't really matter"? The old saw that "anyone can build a bridge that stands up; it takes an engineer to build a bridge that barely stands up" applies.

[ Parent | on HN ]