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

221–230 of 801 posts

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

#221

Post by fenomas »

aphextron wrote: post #43
allover wrote: post #34

Earlier quoted context omitted.

As was pointed out numerous times in that thread, they aren't 'embarassing benchmark numbers', they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code. > But they have no place in text editing. Their popularity proves otherwise.

>they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code I don't think that's true at all. I have tried both VSCode and Atom, and immediately dropped them both after they crashed opening a file of a few thousand lines.

YMMV. I've been a daily user of Code for about a year and I've never seen it crash. Never seen it pause for a perceptible amount of time, that I can recall. Granted, I haven't tried editing any 10MB XML files with it, but then I've only been using it, not benchmarking it.

Sure it uses more memory than nano, but why would I care about that?

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

#222

Post by scriptproof »

tps5 wrote: post #116
Philipp__ wrote: post #50

Earlier quoted context omitted.

Are you kidding me? Look at the raw performances and benchmarks of Vim/Sublime/Emacs, compare it to VSCode and Atom and you will see. If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen. And I still see native editors used more (for example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and…

Clearly a lot of people don't care if their text editor is using "a lot" of memory or "doesn't benchmark well" because all they're doing is writing code and running it occasionally. There's plenty of competition in this area, so if electron-based text editors have enough downsides, people will use something native (as your comment indicates). If that wasn't the case, and we could only choose from electron text editor…

I am sure something like Visual Studio of any other IDE is better suited for a large project.

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

#223

Post by billconan »

billconan wrote: post #111

Yesterday I wrote a webpage with a bootstrap template. The webpage has a progress bar that is updated in realtime by a websocket. The webpage is extremely slow. I guess every bit of progress bar update it rerenders the entire dom tree. I don't think react would do much better, but I will have to try.

why did this get down voted? I can't understand.

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

#224

Post by striking »

fao_ wrote: post #174
gregmac wrote: post #138

Earlier quoted context omitted.

Building a plugin system is hard. Building one that allows creating complex UI elements, modifying other UI elements (from either the core app or other plugins) or changing the way literally anything is rendered is particularly hard. You not only have to build the code that supports all this, you also have to create and document an API and/or markup format to build all this out, plus document all your internal integr…

Or you could use Lisp, and have the UI be S-Expressions. Everything can edit a list

Can you give me an example of a Lisp UI library like that?

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

#225

Post by sfifs »

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.

Very simple, there's a couple of orders of magnitude greater number of developers and designers who have skill with web technologies than native UI. Similarly there's a couple of orders of magnitude more options of UI frameworks and design patterns. Add to the fact that Blink, Webkit, V8 and Chakra have been constantly pushing the bounds on speed bringing a web technology based front end within touching distance in terms of speed vs. native.

Given all these factors, any product using web technologies for UI can move much faster than products which don't. Like how Sublime and every other programming text editor basically got eaten up by VSCode and Atom in about a year and half.

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

#226

Post by DonHopkins »

Rik Arends, who worked on the Cloud9 IDE, has done some amazing work implementing a blazingly fast WebGL based code editor and text formatting and rendering with JavaScript and GPU shaders. He's actually compiling JavaScript code into WebGL shaders!

Implementing a WebGL based code editor for JavaScript - Rik Arends - GrunnJS [1]

How do you render text and update a code editor when it only has vertexbuffers? What can you do with it? What does an AST editor do to help? Rik Arends (founder of Ajax.org/Cloud9) will blow your mind with the talk. Note that this editor is work in progress.

[1] https://www.youtube.com/watch?v=hM1oLr9G3-Q

Here are some other talks about his work:

Rik Arends: Multi-threaded JavaScript inside Makepad [2]

As a web developer since the early 2000s, Rik has lived through the ups and downs of browsers all the way from IE3 to Chrome 52. From doing interactive web projects for big brands to working on Cloud9 IDE, the limitations of HTML have always been there. After leaving Cloud9 four years ago to explore the new possibilities that WebGL offers for UI, a continuous stream of WebGL-related projects have appeared, including a JavaScript trace debugger, a compile-to-JavaScript language and a live coding prototyping framework. Makepad is the latest from-scratch iteration of this WebGL direction, and it is exciting to share the progress and lessons learned.

[2] https://www.youtube.com/watch?v=tVTWdFE6-O0

Rik Arends: Beyond HTML and CSS: Fusing Javascript and shaders | JSConf EU 2014

What would the world look like when you can style UI with actual shader programs? The web could be 60fps on mobile, and we can start to imagine what lies beyond HTML and CSS

[3] https://www.youtube.com/watch?v=X8xxz-YeWtk

Here's a demo! [4]

[4] https://makepad.github.io/makepad.html

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

#227

Post by brulard »

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…

I switched from sublime to Atom maybe 2 years ago. I'm completely happy with the speed. I see no disturbing lags and it works/looks the same on every platform. There is a great extension system and I can develop my own extension quickly if I ever needed to. I believe for the developers it was much more productive to create it with web technology and therefor I don't see any reason why it shouldn't be done like that. I guess there are people that need much faster this or that, and as low memory footprint as possible, but it is not an average user/developer. I believe for most of us these editors work well

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

#228

Post by StyloBill »

big_paps wrote: post #140
StyloBill wrote: post #107

Earlier quoted context omitted.

It's a Chromium problem, maybe you should read the Github issue before commenting.

Still its one of the most interesting posts. x Joules per blink

The maths may be interesting, the rant is definitively not.

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

#229

Post by dvdcxn »

kitsunesoba wrote: post #217
dvdcxn wrote: post #160

Earlier quoted context omitted.

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

Just because it's the best we have (if you're looking for a cross platform solution, anyway) doesn't mean that we've reached the peak and can just quit. We can do a hell of a lot better, and doing anything less is tragically underselling ourselves. There are no laws of physics preventing a better solution from existing. No, creating something better isn't easy, but neither have any of the other technological breakthr…

There are now many more expressive languages which compile to HTML, CSS and JS. We are 'stuck' with these 3 technologies that are still very functional and we should just embrace them as the low level language of UIs.

Of the 3, javascript is the most dispensable, there's nothing stopping us writing platforms which have UIs designed in HTML/CSS but have a DOM controlled by python/c#/ruby.

I was not suggesting we stop progressing, but we need to recognise the phenomenal amount of overhead involved in replacing these 3 technologies. What benefit would be served when they can just be abstracted on top of, at least with regards to the web?

Case in point, Assembly Language, we could theoretically replace the standards that have been reached over decades of collaboration with something more suited to our modern leanings. But what would be the point, when we've long since abstracted it out of our minds?

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

#230

Post by digi_owl »

na85 wrote: post #182
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...

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

Post reply on HN