Live data from Hacker News

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

github.com

601–610 of 801 posts

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

#601
post #235

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…

There really isn't much competition though. Sublime is commercial. Many people don't like emacs or vim. Most other editors are confined to one OS (Notepad++, Kate, etc). When it comes to a full featured, modern editor that works quite well out of the box on most modern OSes, I struggle to come up with any answer other than VS Code.

What's wrong with using Sublime? Quite possibly the best text editor I've ever used. It's snappy, elegant, and it has a boatload of features.

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

#602

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…

This reminds me of one of my favorite old tech stories. A long while back (seems like this was the late 90s or early 2000s) I was working on a script that did some data processing on a remote machine. It had to loop through a bunch of text log data and generate some reports. Being as that I had no idea if the script was actually working until it completed awhile later, I decided to put in a neat little ASCII spinner…

I've got a similar one. I was working on an app once where the current results were being logged to a text box, nothing too fancy, but I noticed it got a lot slower on larger blocks. Changing "textBox.Text = textBox.Text + newline" to "textBox.Append(newLine)" cut >99% of the CPU time.

On the same project I discovered that "System.Envireonment.NewLine" was a relatively expensive call on c#, caching the result of that property was another 50% cut to CPU.

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

#603
post #431

Earlier quoted context omitted.

Luckily there are a few people that still care, just look at the response Handmade Hero has gotten.

Those videos on data oriented design were also very interesting: https://github.com/taylor001/data-oriented-design The thing is, using C++ instead of React for mobile development of a simple application would probably make me miss deadlines... So we just stick to whats popular.

Building UI's in something like Qt, GTK or swing was never really that time consuming, especially given the limited amount of controls one screen in a mobile app.

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

#604
post #601
post #235

Earlier quoted context omitted.

There really isn't much competition though. Sublime is commercial. Many people don't like emacs or vim. Most other editors are confined to one OS (Notepad++, Kate, etc). When it comes to a full featured, modern editor that works quite well out of the box on most modern OSes, I struggle to come up with any answer other than VS Code.

What's wrong with using Sublime? Quite possibly the best text editor I've ever used. It's snappy, elegant, and it has a boatload of features.

I have nothing against Sublime. But I personally don't use closed source text editors. For something that essential to my livelihood, I like knowing should it get abandoned, that there's a chance of others picking it up (even myself).

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

#605

Earlier quoted context omitted.

Also compare Google Docs with Microsoft Word and LibreOffice cold start up time. You will see 2-3 seconds is fast and the two mentioned are not even loaded from a remote resource...

Excel loads in ~1 second...and doesn't have UI lag after it does. Try working with large data sets in Google Docs and you'll have that 2-3 second lag time with _every_ operation you perform.

Or try working with it over an intermittent connection, everything goes haywire.

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

#606
post #548

Earlier quoted context omitted.

I have the same experience on my pretty slow laptop. Granted, my projects aren't big, but I would take vs code over sublime any day. Interestingly, atom feels much slower compared to both.

That's because, unequivocally, atom is slower. https://pavelfatin.com/typing-with-pleasure/

Surprising part isn't that atom is slow, it's that vs code isn't and they both use electron.

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

#607
post #182

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? Ugh, reddit's standard, snarky response: "you do realize... right?" There's simply no way to get around the fact that by and large, many in-browser apps are poorly performant by any modern standard. To me, it seems like there's a faction within the…

The benefit is to their paymasters, as they get to extract rent (either directly or via ads) without having to contend with software pirates because the actual software logic is sitting pretty in a server cluster somewhere. Effectively we are back to the world of time-share terminals.

Ironically, we may yet see a renaissance in native code as more investors realize that the US broadband situation (especially wireless) is not getting better anytime soon. This leads to the realization that always-on, high-speed, low-latency broadband is not a safe assumption. Disconnected operation will become more important as the product space for always-on solutions becomes ever-more crowded.

This realization that always-connected apps might be joined by disconnected apps is emphasized when looking to markets across the world. There are more disconnected people in the world than always-on, high-speed, low-latency connected. There is a burgeoning middle class characterized by sporadic, low-speed, high-latency connections, who are willing to spend some money online, for those times they make it online. They might spend pennies each today, but whoever captures those markets is addressing billions of underserved online customers. I'd take a billion $0.01 payments a day any day.

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

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

> 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 sam…

> You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels [...]

You seem to be misinformed. Of the applications I mentioned, the main ones (gitk, xterm, emacs, xosview) are not doing that; seen clearly by analysing the X traffic.

Of course, some of these could be built with an optional Qt front-end, in which case I would not be surprised.

So you stated clearly "all" applications (for "20 years") which is provably incorrect; and I home in on this because it's a recurrence of another 'well, you never had it before' argument (that really might be better directed at the decaying state of X11 client toolkits)

X11 isn't perfect, I have no doubt something better can be engineered (especially if it involves those who worked on X11). But people are missing the point that to replace X11 is a different matter from designing a better one. It involves acknowledging those who are quietly and successfully using X11 on a daily basis for the majority of their work and existing applications -- not telling us how wrong we are.

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

#609

Earlier quoted context omitted.

If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF. Also the Qt community is minute compared to the JS community, that is significant.

"If you learn how to build doghouses, you can build skyscrapers, bridges, and nuclear power plants." Use the right tools for the job. Trying to shoehorn everything into "the web" makes everything just as shitty as the web.

> Use the right tools for the job

i wonder if this expression constitutes a thought-terminating cliché.

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

#610
post #517

Earlier quoted context omitted.

For those who missed it, n-gate satirizes some HN posts, to the delight of all: http://n-gate.com/hackernews/

Oh my god... n-gate is pure gold!

They had me at "Hacker" "News". Thank you so much for sharing this! (Hell, I mostly quite like HN and I'm sure I'm often part of the problem, and this is still wonderful.)
Post reply on HN