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

181–190 of 801 posts

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

#181

Post by ballenf »

TeMPOraL wrote: post #155
cr0sh wrote: post #120

Earlier quoted context omitted.

...a whole 2-3 seconds! Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud... I know that's a generalization, and most likely unfair - but damn, today's phones, to this old man, are pocket super-computers (for that matter from my vantage point, an Arduino is a wonder, and a RasPi is utterly amazing)!

That's totally unfair. You should compare it to startup time of Word from, I don't know, 10 - 20 years ago. Around the same time (if not less), and Google Docs still can't match the features of old Words. The point being, for the past decade or two, we've been burning all hardware performance improvements on things that are neither visible to user, nor enable them to do more with their computer. Surely, there must be…

On a per-application basis, you are probably correct. But if the additionally abstraction layers allow there to be greater diversity of applications and more tools for more niche cases because development is easier and/or faster, then that is directly immediately beneficial to the end user. Not to mention faster design iteration, implementation of new features etc.

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

#182

Post by na85 »

cr0sh wrote: post #112
dheera wrote: post #40

Earlier quoted context omitted.

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.

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 web development community whose goal is to take things that worked perfectly fine as native apps and re-implement them with poorer performance in the browser, with seemingly no benefit.

I wish these people all the success in the world, if that's what they enjoy doing. But for the most part I simply cannot tolerate the work they produce.

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

#183

Post by 8draco8 »

abritinthebay wrote: post #151
Philipp__ wrote: post #81

Earlier quoted context omitted.

I tried it too... Wasn't satisfied with performances. I used to install Atom every 2,3 months, when VSCode got released I then tried installing it every few months in place of Atom. I still do, but I always uninstall after few hours of using it. It has many good ideas implemented well, but still not worth switching and sacrificing all of the performance for nice git and debugging interface.

VS Code is faster than Atom (by... a lot) tho? Especially with large files, but just in general. Speed is the main reason I can't stay using Atom for more than a few hours. It's awful. VS Code is snappier than Sublime Text ffs...

VSC is not even close of being as snappy as Sublime Text. Sublime also dominates when opening large files (2GB+) and searching trough them.

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

#184

Post by braveo »

rikkus wrote: post #64
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.

We have 'native' text editors. Sublime Text is very similar to VS Code in many ways. But with Sublime I haven't got up and running writing, running, debugging code in various languages like I have in VS Code. The whole experience is important. For many, it's more important than the individual 'feature' of being light on resources. I currently ignore the fact that VS Code is 'heavy' as text editors go, because it's so…

I'm always confused when people say this, I've tried a lot of vim modes and to a T I've never found any that were satisfactory.

I really believe that if you find these vim plugins useful you don't really use vim all that deeply. that's not a criticism, just an observation.

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

#185

Post by Philipp__ »

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…

Ema... Ok ok, I will shut up. :)

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

#186

Post by dheera »

onion2k wrote: post #88
dheera wrote: post #40

Earlier quoted context omitted.

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.

Google Docs takes a good 2-3 seconds to spin up a UI on my i7. I doubt much of that time is spent building the DOM tree for the UI. Google Docs does a lot more than a simple text editing widget - there's a networked file system, a multi-user collaboration engine, a realtime notification system, etc that all get initialised. Instantiating all that over a network in 2-3 seconds is really fast.

> there's a networked file system > a multi-user collaboration engine > a realtime notification system

None of these apply to a new, unshared document. Those subsystems can be loaded slowly over the following 10 seconds, that's fine. Is it such a hard thing to ask to make the UI responsive within 0.1 s? Like, be able to type stuff and have it appear on the screen without delay?

It's so bad that I often use the basic HTML version of Gmail because it loads in less than 1 second. The normal "AJAX" version loads in 3-4 seconds. And I have a 200 megabit connection. Who wins at getting me my information faster?

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

#187

Post by fao_ »

zanny wrote: post #24
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…

We have a lot of native GUI text editors. Gedit, Geany, Kate, and Notepad++ are free options, and then you have Sublime Text as a proprietary one. They all support plugins and extensions, they are all super efficient in CPU usage, etc. The thing is they aren't new, and because they are all C/C++ codebases developers wanting to add new features to text editors don't want to touch C++98 / ANSI C code from two decades a…

> developers wanting to add new features to text editors don't want to touch C++98 / ANSI C code from two decades ago.

As I understand it, sublime has tight enough integration with python, such that python can do literally everything you would ever need

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

#189

Post by Philipp__ »

Kiro wrote: post #122
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…

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

I have used, 6 times, for 1 week period each time. Last time I tried it a month ago.

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

#190

Post by pfooti »

Skywing wrote: post #149

Ah yes. The classic text editor debate thread. In this thread you can expect to find folks claiming that 2 seconds of startup time for editors, like Atom, is so disruptive to their workflow that they'd rather use notepad.

Those kids! On my lawn! When we did it, it was uphill, both ways! I prefer letting butterflies flap their wings to change the atmospheric composition in such a way that the cosmic rays flying through the atmosphere bend to flip bits on this disc.
Post reply on HN