VS Code uses 13% CPU when idle due to blinking cursor rendering • Hacker News Board

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

#271

Post by StreakyCobra » Thu, Mar 23, 2017, 4:39 PM UTC

coldtea wrote: post #179

StreakyCobra wrote: post #168

Earlier quoted context omitted.

By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology…

> By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one You know where else you could do the exact same thing AND have a 10x faster and 10x more memory/battery efficient editor? If a native editor just gave you a webview tha…

> 10x faster and 10x more memory/battery efficient editor?

Except for the startup time --- with which I can live with --- I never felt a difference in speed between native text editors ans VSCode. There is one, but I don't notice it. Human are much more slower than computers, so as long as it is not taking more time that I need to notice it, I don't care.

Nowadays my computer has enough memory so I can afford to not care about the 116M that VSCode is currently using, especially in regard to what my browser consumes, and in regards of the wide range of features it offers.

Battery could be problematic indeed, but before looking at my text editor, I would probably first switch from KDE to i3, and then use a lightweight web browser. This would impact it much more than my text editor.

> If a native editor just gave you a webview that can run JS extensions...

But then you start loosing all the benefits of faster/memory/battery points you mentioned.

Anyway, I'll happily try something like this if you develop it ;-)

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

#272

Post by pantulis » Thu, Mar 23, 2017, 4:39 PM UTC

gmfawcett wrote: post #165

dahauns wrote: post #95

Earlier quoted context omitted.

Lots of emacs functionality runs via its lisp VM. I'd hardly call that 'native'. I mean, Emacs had jokes about being bloated decades before Javascript (and Java, another contender for these jokes) even existed. :)

Most of those jokes are completely out of date. "Eight Megs and Constantly Swapping" used to be a big deal, but today it's not. I don't think running Elisp in Emacs takes away from it being "native." At least insofar as there are no popular text editors (that I know of!) which expect you to compile your plugins and macros to native code. They all have interpreters of one kind or another. What Emacs doesn't have, thou…

Which begs the nice corollary: the definition of "native" doesn't happen to be fixed and changes with time.

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

#273

Post by petters » Thu, Mar 23, 2017, 4:40 PM UTC

ohitsdom wrote: post #101

The Chromium bug describes the root cause, which is a fixed schedule interval for CSS animations: > The JS implementation uses an interval of 500ms between updates while native animations will be updating at 60Hz. At the moment we're not smart enough to deschedule ourselves during animations with step timing functions. https://bugs.chromium.org/p/chromium/issues/detail?id=500259

The fact that animating a cursor at 60Hz requires non-neglible CPU is still a little sad.

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

#274

Post by jstarks » Thu, Mar 23, 2017, 4:40 PM UTC

kardashev wrote: post #268

I think the reason using the browser for desktop UI is because graphics and UI programming is terrible. The computer architecture and operating systems we use today are built on tech that was before graphics existed. That's why it's trivial to build a terminal app, but god help you if you want to create a window with a button or draw a line. GLEW, GLUT, Qt, OpenGL, and the rest are just kludges to deal with the fact…

What hardware or operating system changes do you think are necessary to improve the GUI development experience?

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

#275

Post by veidr » Thu, Mar 23, 2017, 4:41 PM UTC

nojvek wrote: post #38

aphextron wrote: post #16

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…

I don't know why you're saying they are slow. vscode starts up pretty fast. Sure it consumes more resources than vim. However having code completion, debugging, linting, and a bunch of IDE like features is super useful including the fact that it's cross platform and open source. It's very hackable. Just last night I fixed an issue that had been bugging me for a while. Pages with ads use a lot more of my CPU so I'm no…

> I don't know why you're saying they are slow

Because the slowness, when compared to a whole slate of "regular" (== non-web-browser-based) editors, is empirically measurable, and is not just like "twice as slow" or "500% less efficient", but — in many cases, for various operations, as most recently delineated by the joe's own editor benchmarks, but really I mean repeatedly demonstrated over and over for the life of these editors — hundreds of times slower or even infinitely slower (it just gives up and crashes). To a lot of people, that's infuckinsanebro!!!, like a car that gets not n miles per gallon, but needs n gallons per mile.

I get that the extensibility and hackability is appealing. I like that, too.

But at what cost!

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

#276

Post by captainmuon » Thu, Mar 23, 2017, 4:44 PM UTC

StreakyCobra wrote: post #168

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…

By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology…

> For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one.

You could have done that 20 years ago with COM components already. There was a thriving ecosystem where you could get a component for just about everything.

Similar technologies were available on other platforms than Windows, like Bonobo (Gnome), Kparts (KDE), and whatever Mac had.

It's a bit of a shame that component frameworks have gotten such a bad reputation (for complexity and insecurity), I think they are very misunderstood.

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

#277

Post by dekhn » Thu, Mar 23, 2017, 4:44 PM UTC

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.

I build both web apps and Qt apps. TBH, doing something in Qt is about 1/10 to 1/100 the effort of doing it on the web. The web is a morass of confusing standards, none of which work well together. To get guaranteed, predictable behavior which is documented, and will continue to work properly for 10 years after deployment (with only minor maintainence), you simply cannot use the web.

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

#278

Post by [deleted] » Thu, Mar 23, 2017, 4:45 PM UTC

[deleted]

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

#279

Post by shakna » Thu, Mar 23, 2017, 4:45 PM UTC

whazor wrote: post #252

haldean wrote: post #195

Earlier quoted context omitted.

The SO survey (while super interesting!) conflates "most used" with "most asked about on Stack Overflow"; I'm skeptical of anyone who claims to know which programming language is the most popular. The TIOBE index, which has its own problems, has Javascript coming in 8th, with the top 4 being Java, C, C++ and C#; my experiences and my confirmation bias suggest that's more accurate. https://www.tiobe.com/tiobe-index/

I agree that tiobe is more established, especially as they look to companies being involved and to the job market. One of the reasons why I am interested in Javascript is that many people are learning it, even non-developers. Think about people without education.

> Think about people without education.

I don't want people without education building my IDEs and other software I might rely on.

The VS Code team have done a great job, and this bug will die. But, I'd say it's more in spite of the platform, than because of it.

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

#280

Post by StreakyCobra » Thu, Mar 23, 2017, 4:46 PM UTC

rvern wrote: post #238

StreakyCobra wrote: post #168

Earlier quoted context omitted.

By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology…

> Doing the same with native technology would have took several weeks of coding, and it wouldn't have been cross-platform. Actually, it would take one hour because you would use Poppler, and it would be cross-platform. It would also be faster than pdf.js.

> Actually, it would take one hour because you would use Poppler, and it would be cross-platform. It would also be faster than pdf.js.

I don't really know poppler. If there are Poppler bindings for the language you are developing in, I believe you that this is possible. This is only one use case though, I'm not sure you will find native libraries in your language for all features that VSCode can offer almost for free, like live markdown preview for instance.