Live data from Hacker News

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

github.com

571–580 of 801 posts

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

#571
post #366

Earlier quoted context omitted.

The Lisp code is not natively executed. Some features like memory management (garbage collection) are layered on top of the OS. The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems. The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...). etc.etc.

I never said the Lisp code was natively executed. I'm not sure where you got that idea. Let's just agree to disagree. We are talking past each other at this point. Best regards!

[deleted]

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

#572

An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…

I see this argument against electron again and again. Sure, sometimes its overkill - I've seen tray notification apps built with it - but sometimes, it's not. Sure it's not as efficient as something written in .Net, but its a great, hassle free way to go cross platform.

People don't complain that web IDEs are bloated and slow because they need a web browser

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

#573

Earlier quoted context omitted.

I was really looking forward to that write up, as well. Unfortunately, the author must have some rule about not breaking the fourth wall. Or they avoid softballed summaries?

I think a recursive n-gate situation would be delightful. Someone should make this happen.

One Hackernews asks some Hackernews to ask the internet to make a satire about a satire of some Hackernews. Hackernews becomes Stackoverflow.

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

#574
post #200

Earlier quoted context omitted.

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.

That's been my experience as well, although that's still too slow for my tastes as a vim user. But I definitely don't ever recall it being 8 seconds, that feels like either an exaggeration or someone working on a potato.

> that feels like either an exaggeration or someone working on a potato.

Haha, no. It depends on what you use Emacs for. Remember the old joke about Emacs being a great OS? The reality is that Emacs is a great computing environment for almost anything that deals with text and even for some completely unrelated things. If you want a cross-platform GUI then Emacs Lisp may be one of the choices available.

This caused "plugins" - Elisp applications - to flourish and over the years a lot of code was written. Long story short, I have ~640000 (not a typo) lines of Elisp in my ~/.emacs.d/ alone, not counting the built-in Elisp libraries. It takes time to load that much code, even if it's byte-compiled beforehand.

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

#575
post #534

An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…

Best bit is that X11 runs really well these days -- responsive, fast, reliable. Emacs runs great, gitk, xterm, xosview, mplayer window manager, even Firefox is alright. Renoise, Maya, Blender too. Not to mention network transparency when I need it. It's a great environment to get my work done, and 3x hi res displays is the stuff I dreamt of 15 years ago. So it's a good job we're about to throw it all out and start ag…

> Not to mention network transparency when I need it

You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels so this "network transparency" is just buffer copying over the network. Not entirely different from a texture upload to a GPU.

> So it's a good job we're about to throw it all out and start again, eh folks?

Yes, by those of us who have been working on the same platform you claim to love, for the better part of a couple decades.

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

#576
post #533

An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…

You know what would be fast for display updating, ncurses. I wonder why they didn't use that? If only we had an ncurses based text editor.

Someone should write a webkit based ncurses! Why haven't we seen the light before !? ;)

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

#577

An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…

I see this argument against electron again and again. Sure, sometimes its overkill - I've seen tray notification apps built with it - but sometimes, it's not. Sure it's not as efficient as something written in .Net, but its a great, hassle free way to go cross platform. People don't complain that web IDEs are bloated and slow because they need a web browser

Really the argument gets less and less valid over time, for every one of these issues that get discovered, a patch gets made that solves the issue. The platform evolves and gets better until someone else finds an inefficiency, that seems like a pretty typical advancement to me.

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

#578
post #534

Earlier quoted context omitted.

Best bit is that X11 runs really well these days -- responsive, fast, reliable. Emacs runs great, gitk, xterm, xosview, mplayer window manager, even Firefox is alright. Renoise, Maya, Blender too. Not to mention network transparency when I need it. It's a great environment to get my work done, and 3x hi res displays is the stuff I dreamt of 15 years ago. So it's a good job we're about to throw it all out and start ag…

It's the GNOME style of development: as soon as a bug appears which takes effort to fix, mark it EWONTFIX, declare it to be a symptom of the inherent brokenness of the current stack, then burn the whole thing to the ground and start over. Don't even let that which was burned fertilize new growth; it is tainted and must be purged entirely.

How have you managed to make an argument about embedding a web browser about GNOME?

As it were, GNOME's IDE (which I wrote) uses 0% CPU at idle.

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

#579

Earlier quoted context omitted.

I'm glad at least we made fun of both sides. I really wish there was a good option for GUI toolkits. Nearly all are either too primitive to make more than freshmen college (or tenured physics professor) level work or asymptotically approach web browsers without all that tedious attention to improvement and accessibility.

Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.

Such a pity that WPF was never ported to other platforms That's a UI framework that was done right in my opinion. Fast, incredibly flexible and sane.

That it's been relegated to boring internal only enterprise app development is pretty sad. I enjoyed working with it immensely.

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

#580

Earlier quoted context omitted.

You should also sum all the procentages of Intellij based IDEs there, then VSCode is one place down

My whole point is that "most used" is a terrible, terrible metric for anything except for most used.

Not even for the market "voting with their downloads"?
Post reply on HN