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

361–370 of 801 posts

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

#361

Post by Zenst »

artursapek wrote: post #25

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…

IBM spent a humongous amount of man hours upon the running man in smit under AIX, many of those consumed with making sure it ran correctly on all systems of various speeds without the animations going crazy. Alas I don't have exact man hours, but that was what one of the engineers told me a nearly 2 decades ago now. Hopefully somebody else has more detail upon this as one of the earliest examples of progress animations that still runs today that I'm aware of.

I still hark back to the days of the C64 and the likes in which had tape storage and was common to have a game as a loading screen to play. Was a small program and used to give the user something to do whilst they waited 20 minutes for the program to load. Many also rewrote the cassette storage code for faster storage/loading and would often be a case of loading that program with the small game like space invaders that you could play whilst the main game loaded utilising the quicker tape handling code.

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

#362

Post by lispm »

gmfawcett wrote: post #329
lispm wrote: post #311

Earlier quoted context omitted.

GNU Emacs comes with its own portable execution platform (the byte-code Lisp execution engine), where Java applications typically use a provided virtual machine. As such GNU Emacs is just as 'non-native' as a JVM-based editor.

Almost agree with you! If the Emacs VM were used for applications other than Emacs -- if it were a general purpose VM -- then I'd completely agree.

There are lots of applications written on top of GNU Emacs, but most of the time they use the specific UI and features of an editor, or integrate with the editor.

Example: the calculator of GNU Emacs. https://www.gnu.org/software/emacs/manual/html_mono/calc.htm...

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

#363

Post by dheera »

criddell wrote: post #317
mercer wrote: post #220

Earlier quoted context omitted.

Over the past year or two Gmail has gotten really slow. I'm not sure what happened, because there are no new features I can think of that would cause this. It's gotten so bad that I'm considering moving to another provider or using a good old email app again.

I've noticed that too! Do you use Inbox? I do and I was thinking about going back to the classic interface to see if it's faster.

I tried Inbox. I thought for a while that Gmail stars == Inbox pins. When I found out that I was missing out on emails I had previously starred, I quit and went back to Gmail.

Also, Inbox did not show me full e-mails on my Android Wear smartwatch while Gmail did. Also, I couldn't figure out how to set up the filters I needed in Inbox.

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

#364

Post by Kiro »

ovao wrote: post #131
Kiro wrote: post #122

Earlier quoted context omitted.

Have you used VS Code? Feels much more performant than any native editor or IDE I've ever used.

What native editors have you used?

Primarily Sublime Code, Notepad++, PhpStorm and NetBeans.

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

#365

Post by [deleted] »

criddell wrote: post #317
mercer wrote: post #220

Earlier quoted context omitted.

Over the past year or two Gmail has gotten really slow. I'm not sure what happened, because there are no new features I can think of that would cause this. It's gotten so bad that I'm considering moving to another provider or using a good old email app again.

I've noticed that too! Do you use Inbox? I do and I was thinking about going back to the classic interface to see if it's faster.

[deleted]

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

#366

Post by lispm »

gmfawcett wrote: post #325
lispm wrote: post #307

Earlier quoted context omitted.

GNU Emacs Lisp code is certainly not native - not until a JIT will be widespread. GNU Emacs usually compiles Lisp code to a byte code which is interpreted by a byte code engine written in C. If you use a Common Lisp based editor like Clozure CL, Allegro CL and LispWorks have, they don't use a C-based byte code interpreted. The Lisp code is compiled directly to native code. Which makes editor extensions running in nat…

I should be more clear. I don't think that just because Emacs contains an Elisp interpreter, we should call it a "non-native" application -- even if Elisp is integral to Emacs' operation. If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.

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.

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

#367

Post by swalsh »

sbarre wrote: post #358
swalsh wrote: post #23

Earlier quoted context omitted.

It's not slow to me, I find my computer uses far less resources than say one of the million JetBrain IDE's. Combined with a bunch of useful plugins, it's pretty wonderful.

You're comparing a text editor to an IDE. If you are able to do your work with a text editor, maybe you didn't need an IDE in the first place. IDEs are definitely slower than text editors, but they have their benefits that comes with their tradeoffs (like most things).

vscode kind of walks a thin line between IDE and text editor. It has an integrated debugger, intellisense, linting, and plugins to do everything you'd expect from an IDE.

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

#368

Post by symlinkk »

thomastjeffery wrote: post #243
kitsunesoba wrote: post #217

Earlier quoted context omitted.

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…

> it's the best we have (if you're looking for a cross platform solution, anyway) No it's not. If you want a fast full-featured cross-platform GUI toolkit, there are many: GTK+ and Qt are especially great, and have bindings for several languages.

Qt isn't native. They're drawing their own widgets that look close to native - that's why you can theme Qt apps.

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

#369

Post by [deleted] »

thomastjeffery wrote: post #243
kitsunesoba wrote: post #217

Earlier quoted context omitted.

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…

> it's the best we have (if you're looking for a cross platform solution, anyway) No it's not. If you want a fast full-featured cross-platform GUI toolkit, there are many: GTK+ and Qt are especially great, and have bindings for several languages.

[deleted]

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

#370

Post by phkahler »

c-smile wrote: post #352

In GDI era caret bar ( that's not cursor , sic!) was rendered as by simply inverting pixels (InvertRect() call) inplace in video frame buffer. Very cheap operation that does not require redrawing and run of any other code. With the GPU the only viable option for rendering blinking caret is to redraw the whole window. That's why it takes so much CPU as Chrome uses mostly CPU based rasterizer. But redrawing the whole w…

>>In GDI era caret bar ( that's not cursor, sic!) was rendered as by simply inverting pixels (InvertRect() call) inplace in video frame buffer.

And on an old 8-bit system, blinking a cursor involved toggling one byte (character code) in video RAM. How far we have come...

Post reply on HN