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

#301

Post by itake » Thu, Mar 23, 2017, 4:58 PM UTC

veidr wrote: post #275

nojvek wrote: post #38

Earlier quoted context omitted.

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…

have you used VS code? I recently switched from Sublime to VS Code. Originally, I hated the slowness. But the slow point in my work (Software engineer) is not how fast I open files, but on how easy is it for me to transfer what I am thinking to the screen.

VS Code, while slow, has extensions that make me much more productive than when I was using Sublime.

Highlights include:

- auto-formatting my ruby code to fit coding standards. I don't have to spend time mucking with spacing. I write it the fastest way I can, and it fixes it.

- inline git blame. I can easily see who and why a line of code is changed as I select each line. Super useful when debugging. I don't have to kick up the console or fire up github.com in my browser.

- prettify json. I don't have to open up chrome to some json formatting tool to debug my http responses.

edit: I still have to use sublime to open very large files, but that is rare in my work.

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

#302

Post by gmfawcett » Thu, Mar 23, 2017, 4:58 PM UTC

pantulis wrote: post #272

gmfawcett wrote: post #165

Earlier quoted context omitted.

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.

Well, language is like that. :) But I don't think describing Emacs as "native" here is very different from how the word was used decades ago. To me, "native" is less about how the logic is represented (compiled vs. interpreted code) and more about its execution context. If the host system is an operating system, then the application is native; if the host system is another application, then it's not. I agree that the boundary is blurrier for applications that have scripting interfaces; but I think that most applications don't live very close to that boundary, and are clearly in one camp or the other. (Maybe Emacs is nearer to the edge: there's an old joke that Emacs is a great operating system, it just needs a better text editor.)

Having said all that, I don't think that "non-native" is a pejorative. I use Emacs, but would switch to a "non-native" editor if there were a good reason. I use IDEA (native or not? you decide!) when working on big Java projects, and Emacs for everything else, because Emacs affords me a lot of power that I find lacking in other editors. "Nativity" isn't really part of the equation, it's really about functionality.

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

#303

Post by dragonwriter » Thu, Mar 23, 2017, 4:59 PM UTC

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…

> Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, where every noticeable lag and glitches are not appreciated.

There are plenty of native-application (or JVM/CLR) text editors and IDEs, too. For lots of usage patterns, the browser-engine-based ones have acceptable performance, and the number of people with expertise building for web contributes to the speed of development on those editors and their plugins.

But, sure, if you don't like Electron-based editors, there are plenty of other actively-developed editors for you to choose from.

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

#304

Post by efdee » Thu, Mar 23, 2017, 4:59 PM UTC

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.

I can't speak for Qt, but GTK+ is not that great outside of the Linux bubble. IMHO, of course.

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

#305

Post by ksk » Thu, Mar 23, 2017, 5:00 PM UTC

dvdcxn wrote: post #177

coldtea wrote: post #172

Earlier quoted context omitted.

> Why invent a new standard? Because they suck?

Care to argue why? Also, there are countless alternative languages to compile down to HTML or CSS available. Feel free to create your own if none agree with your personal leanings.

Do you want to listen to the reasons, or just tell them to "go make your own if you don't like it"? You can't have it both ways.

I agree that simply saying X sucks is not a valid argument. Howeever with CSS/HTML the flaws are too numerous and already discussed ad nauseam over the past 15 years. Everytime a new version of CSS comes out, people go and try it and find out that it sucks, whether its th broken box model or the broken float layout techniques or the constant fiddling you are forced to do to get anything working. Every web developer I've seen adopts the 'edit and refresh' trial and error model of developing which is the direct result of a bad spec. Which also explains why there isn't even a reference implementation. As far as UI layout is concerned I am fairly sure I could out-compete a web developer in terms of time taken to implement, using something like IMGUI.

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

#306

Post by mixedCase » Thu, Mar 23, 2017, 5:01 PM UTC

StreakyCobra wrote: post #280

rvern wrote: post #238

Earlier quoted context omitted.

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

I don't think the implication you're making here is valid. In Electron you're forced to use JavaScript or a compile-to-JavaScript language. In the desktop it's pretty much the same deal but with C. And we've been doing C FFI since way before JavaScript was conceived.

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

#307

Post by lispm » Thu, Mar 23, 2017, 5:01 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…

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 natively compiled Lisp code.

The advantage of the c-based byte code engine is compact code and improved portability - since the C compiler will already be provided with most platforms, whereas a native Lisp compiler is typically not something provided by a platform (CPU/OS/...) vendor...

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

#308

Post by [deleted] » Thu, Mar 23, 2017, 5:03 PM UTC

stickfigure wrote: post #240

thechao wrote: post #129

Earlier quoted context omitted.

Except that the abstraction layer for the user has remained the same. The extra abstraction layers you're talking about are invisible to the user... while our GUIs are slower, and our processors faster. It feels like, after 30 years, we should be able to have our GUI cake and eat it, too.

Except that the abstraction layer for the user has remained the same. This is absolutely not true. Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos (or control-control sequences for WordStar users like me). Going from desktop apps to webapps changed the abstraction layer of how we access and share documents. No more installing software on…

[deleted]

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

#309

Post by oblio » Thu, Mar 23, 2017, 5:04 PM UTC

tomc1985 wrote: post #290

oblio wrote: post #215

Earlier quoted context omitted.

This arrogance is amusing. The only thing the web and Javascript world proved is that we are bad. In the past it was much harder to distribute crap since you needed to, you know, find and install everything. Since websites are so frictionless, now we get to experience everything. And guess what, 90% of everything is shit. The current "JS devs" are the former "PHP/Java devs" and the former "VB/Delphi devs" and the for…

My problem isn't with the bad JS (or, in the past, PHP/JAVA and so on) devs themselves, it's that they insist on building an ecosystem out of a really bad platform. Why? Because JS and this "leverage existing skillsets" bullshit. How about leveraging your brain to learn a more appropriate language?

Do you know of a "more appropriate" language for creating cross platform apps that work on Windows, Linux, MacOS, BSDs, iOS, Android, 4k screens and 480p screens?

I don't know any.

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

#310

Post by pcwalton » Thu, Mar 23, 2017, 5:04 PM UTC

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.

> instead of a native widget that writes directly to the screen.

"Writing directly to the screen" (by which I assume you mean writing pixels one by one to the framebuffer) is a bad idea for modern graphics hardware. It was fine on the 486, but nowadays you need the ability to do global optimizations for good 2D (or 3D) graphics performance. Ironically, the Web stack is much better positioned to do this than, say, Win32, because of the declarative nature of CSS.

Besides, as some downthread have pointed out, you didn't "write directly to the screen" in Win32. You went through GDI.